MacOS swipe over the tab strip shouldn't navigate back when there aren't enough tabs to scroll
Categories
(Firefox :: Tabbed Browser, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox72 | --- | wontfix |
| firefox73 | --- | wontfix |
| firefox74 | --- | fix-optional |
People
(Reporter: dmolony, Unassigned)
References
(Regression)
Details
(Keywords: regression)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:71.0) Gecko/20100101 Firefox/71.0
Steps to reproduce:
Swiped left in tab bar when all the tabs were already showing.
Actual results:
Browser performed a back-button press.
Expected results:
Nothing. There were not enough tabs to scroll. But when the mouse is in the tab area, it should not change behaviour depending on whether all the tabs are visible.
You cannot tell if all the tabs are showing or not, so you cannot even predict what the swipe will do.
Comment 1•6 years ago
•
|
||
Hi Denis,
Thanks for the details.
I was able to reproduce the bug on MacOS 10.14.5 on Firefox Nightly version 73.0a1 (2019-12-12) (64-bit). When tabs are all visible, swiping right (and not left, as stated above) in tab bar will perform a "back-button press", if there are too many tabs open to be shown, swiping will just scroll among them.
On Firefox Release 71.0 (64-bit), I'm not able to trigger this issue.
Can you please download Firefox Nightly from here: https://nightly.mozilla.org/ and retest the problem and see if the issue still occurs there as well?
I've also chosen a component. If you consider that there's another component that's more proper for this case you may change it.
Best regards,
Clara
| Reporter | ||
Comment 2•6 years ago
|
||
Hi Clara
The problem exists in Firefox Nightly as well as 71.0. And has existed for several releases now.
The reason your swipe direction is different from mine may be due to our settings for Scroll Direction in the control panel. Mine is not 'natural'.
Cheers
Denis
Updated•6 years ago
|
Updated•6 years ago
|
Comment 3•6 years ago
|
||
Hi Clara, can you please try to narrow down a regression range on this bug?
Comment 4•6 years ago
|
||
Hi everyone, sorry for the delay.
@Ryan, I tried doing the mozregression and realized this issue is not reproducible with a new profile.
@Denis, can you check if this issue is happening to you with a fresh profile as well? You can find the steps here: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager
Thanks!
Clara
| Reporter | ||
Comment 5•6 years ago
|
||
Hi all
I created a new profile and opened Firefox using it. The bug still exists.
Comment 6•6 years ago
•
|
||
Hi Denis, would you be able to get a regression range? You can follow these steps:
1- Link to install it on Mac: https://mozilla.github.io/mozregression/install.html
2- Open terminal (cmd space, type terminal)
3- I could isolate the issue and in my case I couldn't reproduce the issue on firefox nightly v70 (that's why I chose 2019-08-01 as the "good" date) but I was able to reproduce it on release v71, beta v72, and nightly v73.0a1 (therefore I chose 2019-10-12 as the "bad" date) You can see the dates in this link https://wiki.mozilla.org/Release_Management/Calendar
I've updated the tracking flags according to the versions where the issue is happening on your end.
Best,
Clara
Updated•6 years ago
|
Updated•6 years ago
|
Comment 7•6 years ago
|
||
61:24.04 INFO: Got as far as we can go bisecting nightlies...
61:24.04 INFO: Last good revision: 950f6d29da967b9999ce709e94bf35b244f79100 (2018-11-30)
61:24.04 INFO: First bad revision: d244292c2a127fafda775e1db5e0a8e4decea5ff (2018-12-01)
61:24.04 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=950f6d29da967b9999ce709e94bf35b244f79100&tochange=d244292c2a127fafda775e1db5e0a8e4decea5ff
I.
Seems like this issue is a regression from 65. Given that the artifacts from 2018 are not available for mozregression, the above range is the best I could do. From the above pushlog, maybe bug 1285812 would be a good regressor choice?
II.
If bug 1285812 is not the regressor, then while enabling "toolkit.tabbox.switchByScrolling" pref, things would get funky (at least on mac) when the tabs are not overflowing: sometimes it would navigate back (or forward-depending on native scroll setting) then with the same swipe also change tabs. I'm uncertain how much support we should have for that pref/feature though.
Dao, thoughts - at least on part II. if bug 1285812 is not the regressor here?
Comment 8•6 years ago
|
||
(In reply to Adrian Florinescu [:aflorinescu] from comment #7)
Seems like this issue is a regression from 65. Given that the artifacts from 2018 are not available for mozregression, the above range is the best I could do. From the above pushlog, maybe bug 1285812 would be a good regressor choice?
That sounds right.
Updated•6 years ago
|
Updated•3 years ago
|
Comment 9•2 years ago
|
||
Clear a needinfo that is pending on an inactive user.
Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.
For more information, please visit BugBot documentation.
Description
•