Font colours change in table with many columns and rows on desktop

Scrabble · August 8, 2026, 11:54am

WHAT IS THE BUG

I built a large table a few days ago and colour coded it. However, the colours for some blocks kept changing as I worked. Came back to it today and again had some colours change. Even now after fixing colours, clicking the backlink, and then opening the page again, the colours have changed. it seems to be the same sections in the table that get affected each time. It also seems to change to the the same ‘changed colour’ each time.

HOW TO REPRODUCE IT

Outline the steps needed to reproduce the behavior in sequence:

Create a table amd change font colours
Leave the window with the table
Go back to the window with the table
ᅟSee changed colours
ᅟI was able to provide a video capture (or screen-shot) of the bug, here it is:

THE EXPECTED BEHAVIOR

Font colours changed for certain blocks. Change it back to the designated colour. Leave screen. Return. Colours for those blocks again changed to the same changed colour. Bug occurs even if I close and launch Anytype again.

ADDITIONAL CONTEXT

n/a

TECHNICAL INFORMATION

OS version: win32 x64 10.0.22631
App version: 0.56.1
Build number: build on 2026-07-28 12:37:12 +0000 UTC at #1aa303c7d30a70dfb951b05a18b6888512e157c2
Library version: v0.50.18
Anytype Identity: A7jVf264gzJQA66vMP8d9heuR1KWusPs2ePUfphmHEn8j81s
Analytics ID: MaStP6eMuPvLWoUGCB4edSo1gGcSRnX24e1yaUrTCX2dg3Yv
Device ID: 12D3KooWED1kDX1Bt3wPZDHATtCD7GRyFBCj6Le52aK4jeWtJwf9
Ethereum Address: 0xF2D58D77542A92D542ceb7e8dffA4cC3fBF82D89

kaye · August 10, 2026, 2:56pm

Thanks for reporting this. Is this issue happening only for tables that are nested in toggles/toggled headings? Or is this happen for your tables across the board?

Scrabble · August 10, 2026, 5:16pm

Hi Kaye, I just did a colour test on a fresh page, not nestled under toggles/toggled headings. Yes, it does seem to happen without toggles.

Interestingly enough, each time a colour change occured it would happen to the same cell. It also would always revert to the same changed colour for both toggled and free form (e.g. if I manually change it to blue and it decides to change to pink, no matter how many times I change it back to blue, it goes back to pink).

Here’s a video of the bug test on a fresh page (not nestled under toggles)

Scrabble · August 10, 2026, 8:21pm

Hi Kaye,

Found another colour bug - it seems to be changing colour in collections as well with the status property.

Just letting you know

kaye · August 11, 2026, 8:17am

Ok, so there’s definitely something stranger happening with your setup. Just a couple more questions:

Have you applied any custom CSS?
Does this happen only in one channel, or in multiple?
Do these colour changes also happen on mobile?

Scrabble · August 12, 2026, 6:55pm

Hi Kaye,

No custom CSS - still very new and learning Anytype
Yes it happens on more than one channel
Yes it also happens on mobile

Thanks for looking into this!

requilence · August 13, 2026, 1:05pm

Thanks for the detailed reproduction steps and video. I was able to reproduce the issue and fix it. The fix will be included in the next release:

github.com/anyproto/anytype-ts

fix(editor): stop mark helpers rewriting the block's stored marks (JS-9853) (#2340)

develop ← fix/JS-9853-mark-toggle-mutation

opened 10:52AM - 13 Aug 26 UTC

requilence

+192 -12

Closes JS-9853 ## Problem Pick a text colour on a selection — works. Pick a **…different** colour on the same selection — the UI repaints but no `BlockSetText` RPC is sent, so the change is lost on reload. The only way to make it save again is to reset to Default and pick the colour again. Investigation showed the reported colour case is one of several. These writes were all being silently dropped, verified by running each scenario through the real `blockSetText` guard against the pre-fix code: | User action | Pre-fix | |---|---| | Recolour the same selection again *(the reported bug)* | **lost** | | Change the background colour of the same selection | **lost** | | Un-bold / un-italicise / un-underline the **left edge** of an existing run | **lost** | | Same on the **right edge** | **lost** | | Extend a colour run **leftwards** by re-applying the same colour | **lost** | | Same **rightwards** | **lost** | | Change an existing link's URL over the same range | **lost** | | Un-bold the middle of a run *(splits it)* | ok | | Recolour a superset of an existing run | ok | ## Root cause The mark helpers mutated the array they were given instead of returning a new one. Those objects are the block's **stored** marks: ``` block.content.marks (store) → marks prop → marksRef.current (component/block/text.tsx:71, re-aliased at :153) → menu data.marks → Mark.toggle input ``` `M.Mark` fields are MobX `observable` (`model/content/text.ts:14-18`), so writing `el.param` / `el.range.from` went straight into the store. The no-op guard in `U.Data.blockSetText` (`lib/util/data.ts:578`, added by the JS-9826 concurrent-text-loss fix) then compared the incoming marks against a store that had *already been updated by the mutation*, found them identical, and returned without emitting `BlockTextSetText`. That is also why the bug was invisible: the mutation re-rendered the block, so the colour appeared to apply while the write was being discarded. Three separate mutators, all fixed in `src/ts/lib/mark.ts`: 1. **`toggle`** — the `Equal` branch did `el.param = mark.param`; `InnerLeft` / `InnerRight` / `Inner` / `Left` / `Right` all edited `el.range` in place. Now copies each mark before grouping, matching the pattern `Mark.adjust` already uses. 2. **`toggleLink`** — spliced the caller's array in place. Now filters into a new list. 3. **`checkRanges`** — `.slice()` copies the array but not the marks inside it, and the loop wrote `mark.range.from/to` and `prev.range.to` through to the caller's objects. `Mark.toHtml` calls it on **every render** with `marksRef.current`, so merely rendering a block rewrote ranges in the store: adjacent same-param marks were merged in place while the removed one stayed in the caller's array, leaving an overlapping duplicate that a later mark-only change could then compare equal against. All 12 callers of `toggle`/`toggleLink` and all 15 of `checkRanges` already use the return value, so nothing depended on the mutation. ## Scope - **Covered:** text colour, background colour, B/I/U/S/code from the toolbar and from keyboard shortcuts, links (context menu and hover preview), and text inside **table cells** (same component, same path). - **Not affected, before or after:** multi-block selection, which goes through `C.BlockTextListSetMark` — a server-side toggle that never touches `Mark.toggle`. The emoji and mention menus already passed `U.Common.objectCopy`. - **Chat:** improved incidentally. While editing an existing message, `marks.current` aliases the stored message marks, so the formatting toolbar was mutating `S.Chat` in place. Chat has no no-op guard, so nothing was lost there, but unsaved formatting rendered and survived cancelling the edit. ## Tests 17 tests added to `src/ts/lib/mark.test.ts`: - Non-mutation assertions for `toggle`, `toggleLink` and `checkRanges`. - A `guard:` block asserting each user action above stays visible to the `blockSetText` comparison — this encodes the *actual* failure mode, which the non-mutation tests only imply. - A negative control: an unchanged selection must still compare equal, so a future "fix" that simply deletes the guard fails here. The guard exists for the JS-9826 / JS-9285 concurrent-edit reason and must stay. **Verified against the pre-fix `mark.ts`: 13 of the new tests fail there and pass here.** Full suite: 90 failed / 616 passed vs. a baseline of 90 failed / 599 passed — same pre-existing failures, no regressions. `typecheck` and `eslint` clean. ## Not in this PR Two related bugs of the same class were found during review and are being filed separately: - `component/block/text.tsx:772` pushes an inline-code mark straight into the store array. Harmless in normal text blocks (the keyup handler reassigns the ref and breaks the alias), but `canHaveMarks()` is `false` for **title and description** blocks so that reassign never runs — backticking a word in a page title renders monospace and saves nothing. - `setText`'s own early-return (`text.tsx:1291`) compares text only, so a mark-only change is invisible to it when `update = false`. ## Manual check Change text colour twice on the same selection without touching the selection in between, reload, confirm the second colour persisted. Then: bold a phrase, select just its first half and un-bold — reload and confirm. Same for a link URL change. Worth repeating inside a table cell.

Scrabble · August 13, 2026, 6:23pm

Thank you so very much! I really appreciate you guys (devs at Anytype!)