Skip to content

Comments

fix: correct stale toolbar button state on arrow key navigation#11191

Open
DiegoCardoso wants to merge 1 commit intomainfrom
fix/rte/active-state-issue
Open

fix: correct stale toolbar button state on arrow key navigation#11191
DiegoCardoso wants to merge 1 commit intomainfrom
fix/rte/active-state-issue

Conversation

@DiegoCardoso
Copy link
Contributor

Summary

  • Fixes toolbar buttons in vaadin-rich-text-editor showing the previous cursor position's format instead of the current one when navigating with arrow keys
  • Works around a Quill 2.0 regression where selectionchange fires before the browser commits the new cursor position, causing getSelection() to return stale data
  • Adds a keydown listener that defers a corrective toolbar update via requestAnimationFrame for navigation keys (Arrow*, Home, End, PageUp, PageDown)

Test plan

  • New test in toolbar.test.js verifies stale toolbar state is corrected on navigation keydown
  • Verified test fails without the fix, passes with it
  • Full RTE suite passes (192/192)
  • Manual verification: navigated between Bold/Italic lines with arrow keys, toolbar updates immediately

Fixes #11184

🤖 Generated with Claude Code

Quill 2.0's selectionchange handler reads the selection before the
browser commits the new cursor position, causing toolbar buttons to
show the previous position's format. Work around this by deferring
a corrective toolbar update via requestAnimationFrame on navigation
keydown events.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@DiegoCardoso DiegoCardoso force-pushed the fix/rte/active-state-issue branch from d694ca2 to 2a32fc7 Compare February 23, 2026 17:15
@sonarqubecloud
Copy link


// Force toolbar into stale state by updating with wrong range
// (simulates Quill 2.0 reading old selection on arrow key navigation)
toolbar.update({ index: 0, length: 1 });
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to simulate this? Shouldn't this be observable just by using key presses?

expect(boldBtn.part.contains('toolbar-button-pressed')).to.be.true;
expect(italicBtn.part.contains('toolbar-button-pressed')).to.be.false;

// Dispatch navigation keydown — our fix should correct the stale toolbar
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Referencing "our fix" doesn't help with code comprehension in the future

Comment on lines +393 to +394
cancelAnimationFrame(this.__toolbarUpdateRaf);
this.__toolbarUpdateRaf = requestAnimationFrame(() => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having the __toolbarUpdateRaf property feels a bit over-engineered/unnecessary.

Even if the component gets disconnected on keydown (but before the raf executes), it doesn't seem to be an issue. If you want, you could check for this.isConnected inside the block.

The debouncing doesn't seem to bring value either since the raf typically executes before the next keydown event anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[rich-text-editor] Button active state toggling is delayed

4 participants