2014761 - Splitter can't be moved to the left side using keyboard arrows if it was moved to the maximum on the right side

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser: Split View, defect, P2)

Description

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Found in

• 149.0a1 (2026-02-04)

Affected versions

• 149.0a1 (2025-02-04)

Tested platforms

• Affected platforms: macOS 26, Ubuntu 24, Windows 11
• Unaffected platforms: none

Steps to reproduce

1. Create a Split View and use the Tab key to select the splitter.
2. Use the right arrow key to resize the Split View to the maximum size.
3. Try to bring back the splitter using the left arrow key.

Expected result

• The splitter moves as expected.

Actual result

• The splitter no longer moves only after the mouse is used.

Regression range

• Not a regression. Happens after the implementation of bug 2012633.

Additional notes

• This also happens when we first move the splitter to the maximum size on the right and then try to bring it back using the left arrow key.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 2012633

:sfoster, since you are the author of the regressor, bug 2012633, could you take a look?

For more information, please visit BugBot documentation.

Comment 2

[Sam Foster [:sfoster] (he/him)]

Thanks for filing. I thought I saw something like this during testing but I didn't pin down the circumstances.
I did notice while implementing bug 2012633 that its possible to drag the splitter out past the width of its container - in terms of the coordinates it reports. There's something funky going on in the measurements there.

Comment 3

[Sam Foster [:sfoster] (he/him)]

It seems like the splitter will eventually move if you keep hammering the left arrow. I counted 20 keypresses before it moved again. At 5px per key down, that's 100px getting lost somewhere. Interestingly, you can reproduce the same thing with the mouse: drag the splitter all the way to the right. Then start dragging it to the left - the pointer moves about 100px before the splitter starts moving.

Comment 4

[Sam Foster [:sfoster] (he/him)]

Attachment: Bug 2014761 - Constrain the splitter to actual max width/height when handling arrow keys. r?emilio!

Comment 5

[Eitan Isaacson [:eeejay]]

Access s2 because of impacted keyboard operability.

Comment 6

[Sam Foster [:sfoster] (he/him)]

This can't be a regression as prior to bug 2012633 the feature did not exist - the splitview splitter was not focusable by keyboard and moving it at all was impossible without a pointer device.
I do agree it needs fixing - there's a patch in-flight.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/0625e18cfee6
https://hg.mozilla.org/integration/autoland/rev/7fc5f2db111e
Constrain the splitter to actual max width/height when handling arrow keys. r=emilio,tabbrowser-reviewers,layout-reviewers,sthompson

Comment 8

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/7fc5f2db111e

Comment 9

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Verified fixed with Firefox 149.0a1 (2026-02-16) on Windows 11, macOS 26 and Ubuntu 24. The Splitter is no longer stuck after being moved at maximum on the left or right side using the arrow keys.
Note: sometimes after resizing to the maximum left or right using the mouse, the splitter dragging area is offset. This is not a regression and does not depend on this issue. I have filed bug 2017216 for that.