Scrolling in tab bar to change tabs doesn't work when scrolling near the window controls (with toolkit.tabbox.switchByScrolling=true)
Categories
(Toolkit :: XUL Widgets, defect, P5)
Tracking
()
Tracking | Status | |
---|---|---|
firefox73 | --- | unaffected |
firefox74 | --- | affected |
People
(Reporter: adrian, Unassigned)
References
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0
Steps to reproduce:
- Enable
toolkit.tabbox.switchByScrolling
inabout:config
- Open a bunch of tabs
- Use the mouse wheel while hovering the tab bar (but not a tab)
Actual results:
Nothing.
Expected results:
Just like when hovering a tab, the mouse wheel should switch between tabs.
This worked fine in previous versions (69 for sure, 70 as well I think).
OS is Windows in case this functionality is platform-specific.
Comment 2•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 3•5 years ago
|
||
The priority flag is not set for this bug.
:dao, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•5 years ago
|
Comment 4•5 years ago
|
||
Confirmed functionality as per Adrian's note with 67.0.1 as well as the issue still being present on 74.0a1 (2020-01-20).
Notes:
- 73.0b7 is not affected by this issue.
- issue appears to be limited to Windows OS.
Regression range:
- Pushlog URL
- last good build_date: 2019-10-02 changeset: c9c63f8447027d14ec2c541e82aae1014f08f812;
- first bad build_date: 2019-10-03 changeset: 2e1bfb7458de41a36432671c405eee62d897a761;
- mozregression points at 1514926 regressor.
@Brian, when you have time, mind taking a look and confirming if this is the case?
Thank you!
Updated•5 years ago
|
Comment 5•5 years ago
|
||
(In reply to Cristian Fogel, QA [:cfogel] from comment #4)
Confirmed functionality as per Adrian's note with 67.0.1 as well as the issue still being present on 74.0a1 (2020-01-20).
Notes:
- 73.0b7 is not affected by this issue.
- issue appears to be limited to Windows OS.
Regression range:
- Pushlog URL
- last good build_date: 2019-10-02 changeset: c9c63f8447027d14ec2c541e82aae1014f08f812;
- first bad build_date: 2019-10-03 changeset: 2e1bfb7458de41a36432671c405eee62d897a761;
- mozregression points at 1514926 regressor.
@Brian, when you have time, mind taking a look and confirming if this is the case?
Thank you!
I would have thought the fix in Bug 1601184 would have also fixed this.
I'm also surprised that it's working in 73 but not 74. So presumably something landed that fixed it in 73 but then something else landed that broke it in 74. Any chance you could bisect the pushlog fixed it in 73.0b7?
Comment 6•5 years ago
|
||
Unless it's something cache related combined with mozregression rechecking, I've noticed that in fact 73.0b7 + 67.0.1 might also (still) be affected by this particular issue.
Thus making the report + my regression range invalid.
As per the attachment, the key aspect of this issue would be the position, on which the scroll_event on bar is picked up.
Bassically:
- with 1-2 tabs the available area in which to scroll is plenty;
- with the max_nr of tabs displayed, the available scroll area is reduced to tabs and +button;
- with the max_nr - 1, there is some space in between the +button(OpenNewTab) and window_control buttons;
- having the browser maximized or not has no influence over this.
While changing the number of tabs the available scroll_area adjusts its self.
Now, since is the most likely cause for the report, the empty space in between the +button and window_controls would need clarification; if it should pick up the scroll_action or not (as per intended behavior); when enough the tabs are open so they don't push the +button anymore.
Comment 7•5 years ago
|
||
(In reply to Cristian Fogel, QA [:cfogel] from comment #6)
Created attachment 9122638 [details]
sroltab.gifUnless it's something cache related combined with mozregression rechecking, I've noticed that in fact 73.0b7 + 67.0.1 might also (still) be affected by this particular issue.
Thus making the report + my regression range invalid.As per the attachment, the key aspect of this issue would be the position, on which the scroll_event on bar is picked up.
Bassically:
- with 1-2 tabs the available area in which to scroll is plenty;
- with the max_nr of tabs displayed, the available scroll area is reduced to tabs and +button;
- with the max_nr - 1, there is some space in between the +button(OpenNewTab) and window_control buttons;
- having the browser maximized or not has no influence over this.
While changing the number of tabs the available scroll_area adjusts its self.
Thanks for following up. It sounds like this is a valid bug, but that it's not a regression triggered by Bug 1514926.
My guess is that the original report here is a duplicate of Bug 1601184 and was fixed in 73 but that you discovered a separate bug here, maybe related to the scroll not being captured when it's too close to the window controls? I'm going to morph this bug into what you've found in Comment 6 tentatively. As a sanity check, I'm needinfo'ing the original reporter to see if they can confirm that their original issue is fixed for them in 73 (easiest way to test this would be to test with a new profile in Nightly).
Now, since is the most likely cause for the report, the empty space in between the +button and window_controls would need clarification; if it should pick up the scroll_action or not (as per intended behavior); when enough the tabs are open so they don't push the +button anymore.
I don't know the intended behavior here. I guess it's expected to respond to the scroll event, but since this seems like a bit of an edge case on top of being present only behind an off-by-default pref I don't think it'll be a high priority to fix.
You promised that you fix the "toolkit.tabbox.switchByScrolling:true" function in Firefox 73, but the problem remains the same. Tabs can be turned over with the mouse wheel only in the visible part. When there are a lot of tabs and they go abroad, then switching the tabs with the mouse wheel no longer works, only navigation works.
Comment 9•5 years ago
|
||
(In reply to veron from comment #8)
You promised that you fix the "toolkit.tabbox.switchByScrolling:true" function in Firefox 73, but the problem remains the same. Tabs can be turned over with the mouse wheel only in the visible part. When there are a lot of tabs and they go abroad, then switching the tabs with the mouse wheel no longer works, only navigation works.
Are you referring to the mouse wheel not working when near the window controls (minimize, maximize, close) as shown in comment 6? Or in any empty space in the tab bar? The latter should be fixed in 73 from Bug 1601184 - if you're not seeing that, could you post a screencapture of the problem or write down the steps to reproduce the problem?
Comment 10•5 years ago
|
||
Mouse wheel scrolling does not work on all tabs outside the border.
Comment 11•5 years ago
|
||
(In reply to Brian Grinstead [:bgrins] from comment #9)
if you're not seeing that, could you post a screencapture of the problem or write down the steps to reproduce the problem?
Yes, I attached a gif image - https://bug1592798.bmoattachments.org/attachment.cgi?id=9125892
Comment 12•5 years ago
|
||
Will my answer be considered and what solution?
Updated•5 years ago
|
Comment 13•5 years ago
|
||
brian: FYI, is this still p5? any other updates?
Comment 14•5 years ago
|
||
(In reply to Randell Jesup [:jesup] (needinfo me) from comment #13)
brian: FYI, is this still p5? any other updates?
Are you seeing the original reported issue or the issue described in Comment 8 and 10? If the latter, I'd be interested in more concrete STR - it's hard for me to tell from the gif exactly when it stops working.
As per Commnent 6, the original issue (scrolling on/near window controls in Windows) has been present since 67, so I'm unmarking this as a regression.
Comment 15•5 years ago
|
||
I'm not the reporter; I was looking at this bug as part of the weekly Regression Triage. You NI'd the reporter a month ago, and he hasn't responded yet. Veron, can yo verify the original report? And can you give more detailed STR - Steps To Reproduce? Thanks
Comment 16•5 years ago
|
||
(In reply to Randell Jesup [:jesup] (needinfo me) from comment #15)
Veron, can yo verify the original report? And can you give more detailed STR - Steps To Reproduce? Thanks
Sorry, i bad understand English well. I communicate through Google Translate.
You are not enough gif images (https://bugzilla.mozilla.org/attachment.cgi?id=9125892) on my question?
Everything is very simple and easy to check. Switching between tabs with the mouse wheel works only in the visibility zone. As soon as there are more tabs and they go beyond the border of the screen, switching tabs with the mouse wheel stops working.
Comment 17•5 years ago
|
||
Why did you stop responding? Will this problem be fixed?
Comment 18•5 years ago
|
||
(In reply to veron from comment #16)
(In reply to Randell Jesup [:jesup] (needinfo me) from comment #15)
Veron, can yo verify the original report? And can you give more detailed STR - Steps To Reproduce? Thanks
Sorry, i bad understand English well. I communicate through Google Translate.
You are not enough gif images (https://bugzilla.mozilla.org/attachment.cgi?id=9125892) on my question?Everything is very simple and easy to check. Switching between tabs with the mouse wheel works only in the visibility zone. As soon as there are more tabs and they go beyond the border of the screen, switching tabs with the mouse wheel stops working.
I think what's happening is that once the scrollbox overflows, the mouse wheel begins controlling the scrollbox scroll poition instead of switching tabs. This is different from the reported bug here, so I'll clone this one and make it into a new report.
Updated•5 years ago
|
Updated•2 years ago
|
Description
•