Table editor error: Cannot read properties of null (reading 'length') persists on 2026.2.0-latest

Contribute Bug
,

AI-generated summary

User Ethsim2 reported a persistent bug in Discourse v2026.2.0-latest where the table editor throws a Cannot read properties of null (reading 'length') error when saving, even in Safe Mode. The issue affects tables containing LaTeX formatting, such as this example involving dielectric constants. While sam initially could not reproduce the issue with a standard table, Ethsim2 provided the specific markdown causing the failure.

The root cause was identified as a reliance on regex for table detection, which failed with complex formatting. This was addressed in PR #37658, which switches to more robust markdown parsing sam. However, Ethsim2 noted that their instance (commit 8125ffa60a) predates this fix and the issue persists until the latest version is updated past the merge Ethsim2.

1

Continuing the discussion from Unable to edit tables:

Hi all, following up with more concrete data.

I can confirm this issue is still reproducible on latest.

Environment

  • Discourse: v2026.2.0-latest +209 (after full rebuild)
  • Previously also observed on: v2026.2.0-latest +165
  • Browser: Chrome

What I’ve tried

  • Full rebuild / update to +209
  • Hard refresh
  • Reproduced in Safe Mode with:
    • themes disabled
    • unofficial client-side customisations disabled
    • all client-side plugin customisations disabled

Result

  • Editing a table and clicking the blue Save button consistently throws:
Uncaught TypeError: Cannot read properties of null (reading 'length')
  at buildUpdatedPost (spreadsheet-editor.gjs:261)
  at updateTable
  at insertTable
  • UI does not save or update the post.
  • Same behaviour occurs in Safe Mode.
Screenshots attached showing the console error and Safe Mode reproduction.

not safe mode

image
image1407×360 125 KB

safe mode

image
image1340×637 181 KB

2
Column 1 Column 2 Column 3 Column 4 Column 5 Column 6 Column 7 Column 8 Column 9 Column 10
Row 1, Cell 1 Row 1, Cell 2 Row 1, Cell 33 Row 1, Cell 4 Row 1, Cell 5 Row 1, Cell 6 Row 1, Cell 7 Row 1, Cell 8 Row 1, Cell 9 Row 1, Cell 10
Row 2, Cell 1 Row 2, Cell 2 Row 2, Cell 3 Row 2, Cell 4 Row 2, Cell 5 Row 2, Cell 6 Row 2, Cell 7 Row 2, Cell 8 Row 2, Cell 9 Row 2, Cell 10
Row 3, Cell 1 Row 3, Cell 2 Row 3, Cell 3 Row 3, Cell 4 Row 3, Cell 5 Row 3, Cell 6 Row 3, Cell 7 Row 3, Cell 8 Row 3, Cell 9 Row 3, Cell 10
3

Not reproducible here (trivially)

Is it something about your particular table? Can you include full markdown?

4 
Material | $\varepsilon_r$
-------- | --------------
Dry air  | 1.0006
Paper    | 3
Diamond  | 5
Silicon  | 12
HfO $_2$  (Hf = Hafnium) | 25
H $_2$ O   | 80
BaTiO $_3$ (Barium Titan - useful for keeping its polarisation) | $\sim 4000$
Material \varepsilon_r
Dry air 1.0006
Paper 3
Diamond 5
Silicon 12
HfO _2 (Hf = Hafnium) 25
H _2 O 80
BaTiO _3 (Barium Titan - useful for keeping its polarisation) \sim 4000
1 Like
6

OK this is fixed per:

https://github.com/discourse/discourse/pull/37658

We were leaning on regex to find tables and it did not like this table format.

The change is to lean on markdown parsing which is much more robust.

2 Likes
7

I’m currently on 2026.2.0-latest (8125ffa60a).

The issue still reproduces there, including in Safe Mode and PWA.

Looks like this commit predates PR #37658 - happy to retest once latest advances past the merge.

8

This topic was automatically closed after 5 days. New replies are no longer allowed.