Closed Bug 1511613 Opened 6 years ago Closed 3 months ago

Unpredictable mouse wheel scroll behavior in tab strip when close to overflowing

Categories

(Toolkit :: UI Widgets, defect, P5)

65 Branch
Unspecified
Linux
defect

Tracking

()

RESOLVED DUPLICATE of bug 1625945
Tracking Status
firefox63 --- unaffected
firefox64 --- unaffected
firefox65 --- disabled
firefox66 --- disabled

People

(Reporter: ke5trel, Assigned: kroylar)

References

Details

(Keywords: regression, ux-mode-error)

Attachments

(1 file, 1 obsolete file)

Bug 1285812's approach of different mouse wheel scroll behavior in the tab strip based on whether it is overflowing makes it prone to mode error, producing unpredictable results. Users with small numbers of tabs will get used to using the scroll wheel to switch tabs which will suddenly stop working when they overflow. Users with large numbers of tabs, used to using the scroll wheel to see more tabs, will suddenly start switching tabs when they drop below the overflow amount. Users that have a tab count that hovers near the overflow amount will constantly have to keep track of the overflow state to know what will happen when they scroll. The overflow state is not visually obvious, indicated only by small arrows at the ends of the tab strip. When reaching the end of the strip, one of the arrows is greyed out making it even harder to notice. Accidentally switching tabs due to mode confusion may be highly undesirable, causing unwanted tabs to load and play audio.
Priority: -- → P5
Maybe the "tab switching via scrolling" behavior on tab bar overflow could be enhanced by: A) Adding an about:config option to always switch tabs even when scrolling on an overflowing tab bar. B) Adjusting the current behavior where on overflow scrolling slides to previously invisible tabs like this: 1) When the last visible tab is reached start sliding to show the previously invisible tabs. 2) But when the user stops scrolling and the current tab is not the last visible tab (e.g. the current tab is somewhere in the middle of the tab bar) scrolling should start to switch tabs again. 3) If the current tab is not among visible tabs scrolling should continue to perform the sliding of tabs in the tab bar. Note that this is just an initial idea and I am not sure how difficult it would be to implement B).

This feature is off by default across all affected versions now.

See Also: → 1550094

This patch causes the mouse scroll wheel to actually switch tabs even if the tabs are overflowing. I believe this is the correct and most consistent behavior.

I used git to commit and format the patch because that choice was offered to me when first setting up my mozilla build environment with bootstrap.py. If I should instead re-run bootstrap.py and use mercurial, I am willing to do that. This is my first submission to mozilla (although I accidentally uploaded it to the closed 1550094 before this).

Hi dao, can you please comment on my patch? This removes the inconsistent behavior that was introduced in bug 1285812.

Component: Tabbed Browser → XUL Widgets
Product: Firefox → Toolkit

As I mentioned in Freenode submitting it through Phabricator is the preferred workflow for patches these days. https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#submitting-patches

Previously, the toolkit.tabbox.switchByScrolling parameter would allow
one to scroll the mouse wheel to switch tabs. However if the tabbox was
ever overflowing, the mouse wheel event would be eaten by the
arrowscrollbox. This resulted in inconsitent behavior.

This patch will prevent the arrowscrollbox from using the mouse scroll
event if the toolkit.tabbox.switchByScrolling preference is true.

Assignee: nobody → kroylar
Status: NEW → ASSIGNED
Attachment #9122807 - Attachment description: Bug 1511613 - toolkit.tabbox.switchByScrolling works even if overflowing, r=dao → Bug 1511613 - toolkit.tabbox.switchByScrolling works even if tabs are overflowing, r=dao

Could this please be reviewed again? kroylar's patch with applied ntim's suggestion works well for me, I wasn't able to detect any regressions.

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: kroylar → nobody
Status: ASSIGNED → NEW
Severity: normal → S3
Status: NEW → RESOLVED
Closed: 3 months ago
Duplicate of bug: 1625945
Resolution: --- → DUPLICATE
Assignee: nobody → kroylar
Attachment #9122807 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: