You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-[Feature Activation and Rollout Plan](#feature-activation-and-rollout-plan)
25
25
-[Privacy and Security Considerations](#privacy-and-security-considerations)
26
26
-[Performance Impact](#performance-impact)
27
27
-[Interoperability](#interoperability)
@@ -48,7 +48,7 @@ This makes the current caret movement visually inconsistent:
48
48
49
49
This behavior is confusing and disorienting, particularly for users who routinely work with bidirectional content.
50
50
51
-
This explainer proposes implementing **visual caret navigation** in Chromium -- arrow key movement that always follows the on-screen direction, so that Right moves the caret rightward and Left moves it leftward regardless of text or line direction. The feature will be gated behind a feature flag for incremental rollout.
51
+
This explainer proposes implementing **visual caret movement** in Chromium -- arrow key movement that always follows the on-screen direction, so that Right moves the caret rightward and Left moves it leftward regardless of text or line direction. The feature will be gated behind a feature flag for incremental rollout.
52
52
53
53
## The Bidirectional Text Problem
54
54
@@ -96,23 +96,25 @@ Visual movement solves this by moving the caret based on its **screen position**
96
96
97
97
4.**Gate behind a feature flag** for safe incremental rollout, with no behavior change for users who do not opt in.
98
98
99
-
5.**Correctly handle all bidi scenarios**: simple LTR/RTL boundaries, multiple bidi runs, nested bidi embeddings, bidi control characters, CSS `direction`/`unicode-bidi` overrides, and cross-line navigation.
99
+
5.**Correctly handle all bidi scenarios**: simple LTR/RTL boundaries, multiple bidi runs, nested bidi embeddings, bidi control characters, CSS `direction`/`unicode-bidi` overrides, and cross-line movement.
100
100
101
101
## Non-Goals
102
102
103
103
1.**Changing selection extension behavior.** Shift+Arrow selection operates on logical DOM offsets. True visual selection across bidi boundaries would require multi-range selection support in Chromium, which does not exist today. This is a potential future extension but is out of scope.
104
104
105
105
## Proposed Solution
106
106
107
-
When the `BidiVisualOrderCaretNavigation` feature flag is enabled, Chromium's arrow key handling switches to visual (screen-order) caret movement. The implementation works by leveraging Blink's existing inline layout fragments, which are already stored in visual display order after bidi reordering. This allows the algorithm to walk through text in the order it appears on screen rather than the order it is stored in memory.
107
+
When the `BidiVisualOrderCaretMovement` feature flag is enabled, Chromium's arrow key handling switches to visual (screen-order) caret movement. The implementation works by leveraging Blink's existing inline layout fragments, which are already stored in visual display order after bidi reordering. This allows the algorithm to walk through text in the order it appears on screen rather than the order it is stored in memory.
108
108
109
109
At a high level:
110
110
111
111
1. When a user presses an arrow key, the caret's current position is resolved to the layout fragment it belongs to.
112
-
2. The caret advances in the visual direction within that fragment. For LTR text, moving right increments the position; for RTL text, moving right decrements it.
112
+
2. The caret advances in the visual direction within that fragment. For LTR text, moving right increments the position; for RTL text, moving right decrements it — in both cases the caret moves rightward on screen.
113
113
3. When the caret reaches the edge of a fragment, it uses the **bidi level** of the current and adjacent fragments to determine which edge to enter — ensuring the caret crosses bidi boundaries smoothly without jumping.
114
114
4. At line boundaries, the caret moves to the next or previous line as expected.
115
115
116
+
Word-level movement (Ctrl+Left/Right on Windows, Option+Left/Right on macOS) and `Selection.modify()` with `'word'` granularity also follow the same visual direction.
117
+
116
118
## The API Surface
117
119
118
120
The existing [`Selection.modify()`](https://w3c.github.io/selection-api/#dom-selection-modify) API already distinguishes visual and logical directions:
With this feature enabled, `'left'` and `'right'` will perform true visual movement in bidi text, while `'forward'` and `'backward'` will continue to perform logical movement. This matches the behavior of Firefox and Safari.
131
133
132
-
## Feature Activation
134
+
## Feature Activation and Rollout Plan
133
135
134
136
The feature is currently gated behind a disabled-by-default runtime flag:
1.**Phase 1 (current):** Feature flag disabled by default. Developers and testers can opt in via the command-line flag above.
143
+
2.**Phase 2:** Expose a `chrome://flags` entry so that users can enable visual caret movement without command-line flags.
144
+
3.**Phase 3:** Enable by default for all users.
145
+
146
+
Until the feature is enabled, caret behavior remains unchanged — existing logical movement continues to work exactly as it does today. No user-visible changes occur without explicit opt-in during Phases 1 and 2.
0 commit comments