Description
The editor toolbar's scroll-indicator gradients are positioned and computed using physical left/right values, and render incorrectly in right-to-left layouts. Confirmed on device: the gradient does not display on the correct side for the current scroll position and overflow content.
Unlike the other physical-property usages in src/, this one cannot be fixed by swapping to logical CSS alone — the CSS and the JavaScript that drives it are coupled, and the JS half depends on how WebKit reports scrollLeft in an RTL container.
CSS — src/components/editor-toolbar/style.scss:44-91
Two different gradients pinned to opposite edges, each with a physical position and a physical gradient direction:
&::before — left: 0, background: linear-gradient(to right, …)
&::after — right: 0, background: linear-gradient(to left, …)
JS — src/components/editor-toolbar/use-scroll-indicators.js:32-34
const canScrollLeft = scrollLeft > threshold;
const canScrollRight = scrollLeft + clientWidth < scrollWidth - threshold;
These set the has-scroll-left / has-scroll-right classes (src/components/editor-toolbar/index.jsx:95-96) that toggle each gradient's opacity.
In an RTL container, browsers report scrollLeft as negative or inverted depending on the engine, scrolling right-to-left from zero. If WebKit does not normalise it, canScrollLeft is never true and canScrollRight misbehaves, so the gradients appear on the wrong edge or not at all.
Step-by-step reproduction instructions
- Set the demo app to a right-to-left language — Arabic or Hebrew. On iOS use the scheme's App Language; on Android use Settings > Apps > GutenbergKit > Language.
- Open the editor and select a block whose toolbar overflows horizontally (add enough formatting controls that the toolbar scrolls).
- Scroll the toolbar in both directions.
- Observe whether the fade gradients appear on the correct edges — the gradient should mark the edge with more content beyond it.
Expected: gradients appear on whichever edge has off-screen content, mirroring correctly in RTL.
Actual: the gradient does not display on the correct side for the current scroll position and overflow content.
The fix spans both the CSS (logical positioning plus gradient direction) and the scroll-state calculation, which needs to account for how scrollLeft is reported in an RTL container.
Environment info
- Affects the GutenbergKit editor in the iOS and Android demo apps, and any host, when running a right-to-left locale.
- Confirmed in the demo app with a right-to-left language selected.
- RTL rendering support was added in the branch that also fixed the toolbar border-side bug; before that the editor never rendered RTL at all, so this would not have been observable.
Description
The editor toolbar's scroll-indicator gradients are positioned and computed using physical left/right values, and render incorrectly in right-to-left layouts. Confirmed on device: the gradient does not display on the correct side for the current scroll position and overflow content.
Unlike the other physical-property usages in
src/, this one cannot be fixed by swapping to logical CSS alone — the CSS and the JavaScript that drives it are coupled, and the JS half depends on how WebKit reportsscrollLeftin an RTL container.CSS —
src/components/editor-toolbar/style.scss:44-91Two different gradients pinned to opposite edges, each with a physical position and a physical gradient direction:
&::before—left: 0,background: linear-gradient(to right, …)&::after—right: 0,background: linear-gradient(to left, …)JS —
src/components/editor-toolbar/use-scroll-indicators.js:32-34These set the
has-scroll-left/has-scroll-rightclasses (src/components/editor-toolbar/index.jsx:95-96) that toggle each gradient's opacity.In an RTL container, browsers report
scrollLeftas negative or inverted depending on the engine, scrolling right-to-left from zero. If WebKit does not normalise it,canScrollLeftis never true andcanScrollRightmisbehaves, so the gradients appear on the wrong edge or not at all.Step-by-step reproduction instructions
Expected: gradients appear on whichever edge has off-screen content, mirroring correctly in RTL.
Actual: the gradient does not display on the correct side for the current scroll position and overflow content.
The fix spans both the CSS (logical positioning plus gradient direction) and the scroll-state calculation, which needs to account for how
scrollLeftis reported in an RTL container.Environment info