Skip to content

fix(sections-editor): stop custom color swatch reverting text to black - #5525

Open
pedrofrxncx wants to merge 1 commit into
mainfrom
fix/rich-text-custom-color-stale-blur-w2
Open

fix(sections-editor): stop custom color swatch reverting text to black#5525
pedrofrxncx wants to merge 1 commit into
mainfrom
fix/rich-text-custom-color-stale-blur-w2

Conversation

@pedrofrxncx

@pedrofrxncx pedrofrxncx commented Jul 31, 2026

Copy link
Copy Markdown
Collaborator

This is a bug fix in the rich-text-color-control added by #5523.

Failure scenario: RichTextColorControl's custom <input type="color"> keeps a local custom state that's initialized once to "#000000" and only ever updated by that input's own onChange. Its onBlur unconditionally calls applyColor(custom). Native color inputs fire blur when the OS color dialog closes even if the user cancels without picking a value (confirmed Chrome/Safari behavior). So: apply a preset swatch (say red), reopen the color popover later to check it, click the custom swatch just to look, then cancel the OS dialog without picking anything — blur still fires, and applyColor(custom) reapplies the stale default "#000000", silently turning the text black even though the user never touched the custom picker.

Fix: resync the custom state to the actually-applied currentColor whenever the popover transitions to open (same local-state-with-external-resync pattern already used by DatePickerInput in string-field.tsx). Canceling the dialog now re-applies the same color that was already there — a no-op — instead of a stale one.

Net change: +10/-1 in apps/web/src/components/sections-editor/rich-text-color-control.tsx.

To verify: apply a preset text color in the rich-text editor's color popover, reopen the popover, click the custom-color swatch, and cancel the native OS color dialog without picking a color — the applied color should be unchanged (previously it would revert to black).

Locally ran: bun run fmt, bunx oxlint on the changed file (0 warnings/errors), bunx tsc --noEmit in apps/web (clean). This is a browser-interaction bug in a Playwright component test area (apps/web/ct/), which this environment can't run (no Playwright) — full CI validates the ct suite.


Summary by cubic

Fixes a bug where canceling the OS color dialog after clicking the custom swatch reverted rich-text to black. The custom color now syncs to the current color when the popover opens, so canceling keeps the existing color.

Written for commit 93a0a57. Summary will update on new commits.

Review in cubic

The custom-color <input type="color">'s local `custom` state never
synced with the actually-applied color — it only updated via its own
onChange. Its onBlur unconditionally re-applies `custom`, and browsers
fire blur on the native color dialog even when the user cancels it
without picking a value. So: apply a preset color, reopen the popover,
click the custom swatch just to look, cancel the OS dialog — blur fires
and silently reapplies the stale default ("#000000"), turning the text
black.

Fix: resync `custom` to the current color whenever the popover opens,
so canceling re-applies the same color instead of a stale one.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant