[focusgroup] support writing direction#58056
Merged
chromium-wpt-export-bot merged 1 commit intomasterfrom Feb 26, 2026
Merged
Conversation
FocusgroupDirectionForEvent previously hardcoded arrow-to-direction mappings (e.g. ArrowLeft → BackwardInline) without consulting the focused element's writing mode or text direction. This meant focusgroup navigation was incorrect in RTL contexts and vertical writing modes. Fix by passing the focused element to FocusgroupDirectionForEvent and using ComputedStyle::GetWritingDirection() to resolve physical arrow keys to logical directions via WritingDirectionMode. This correctly handles RTL (inline axis reversed), vertical-rl, vertical-lr, sideways-rl, and sideways-lr. Changed FocusgroupDirectionForEvent to take a const Element& param Reordered HandleArrowKeyboardEvent to obtain the focused element before resolving direction Added unit tests for RTL, vertical-rl, and vertical-lr Added 4 web tests: RTL inline reversal, RTL inline-only axis, RTL wrapping, and vertical writing mode Bug: 4021071 Change-Id: I6571c631c6ac3c7c0cf8b8e79da754656d15a3da Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7601281 Commit-Queue: Jacques Newman <janewman@microsoft.com> Reviewed-by: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1590474}
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-7601281
branch
from
f8a2c38 to
71eab0b
Compare
wpt-pr-bot
approved these changes
Feb 26, 2026
Collaborator
wpt-pr-bot
left a comment
wpt-pr-bot
left a comment
There was a problem hiding this comment.
The review process for this patch is being conducted in the Chromium project.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
FocusgroupDirectionForEvent previously hardcoded arrow-to-direction
mappings (e.g. ArrowLeft → BackwardInline) without consulting the
focused element's writing mode or text direction. This meant focusgroup
navigation was incorrect in RTL contexts and vertical writing modes.
Fix by passing the focused element to FocusgroupDirectionForEvent and
using ComputedStyle::GetWritingDirection() to resolve physical arrow
keys to logical directions via WritingDirectionMode. This correctly
handles RTL (inline axis reversed), vertical-rl, vertical-lr,
sideways-rl, and sideways-lr.
Changed FocusgroupDirectionForEvent to take a const Element& param
Reordered HandleArrowKeyboardEvent to obtain the focused element
before resolving direction
Added unit tests for RTL, vertical-rl, and vertical-lr
Added 4 web tests: RTL inline reversal, RTL inline-only axis,
RTL wrapping, and vertical writing mode
Bug: 4021071
Change-Id: I6571c631c6ac3c7c0cf8b8e79da754656d15a3da
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7601281
Commit-Queue: Jacques Newman <janewman@microsoft.com>
Reviewed-by: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1590474}