Closed Bug 1473595 Opened 6 years ago Closed 6 years ago

Enable "Ctrl+Tab cycles through tabs in recently used order" feature by default in new profiles

Categories

(Firefox :: Tabbed Browser, defect, P3)

Product:
Firefox
Component:
Tabbed Browser
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 63
Tracking Flags:
Tracking Status
relnote-firefox --- 63+
firefox-esr52 --- wontfix
firefox-esr60 --- wontfix
firefox61 --- wontfix
firefox62 --- wontfix
firefox63 --- verified

People

(Reporter: bwinton, Assigned: dao)

References

(Depends on 1 open bug)

Details

Attachments

(1 file)

Bug 1473595 - Enable "Ctrl+Tab cycles through tabs in recently used order" feature by default in new profiles.
59 bytes, text/x-review-board-request
jaws
: review+
Details
It's a very nice UI, we should give it to everyone by default!
(In reply to Blake Winton (:bwinton) (:☕️) from comment #0) > It's a very nice UI, we should give it to everyone by default! Is this formally approved by UX? Should we enable it for all users or in new profiles only?
Component: Keyboard Navigation → Tabbed Browser
Flags: needinfo?(bwinton)
Priority: -- → P3
Depends on: 1116787
(I've asked Philipp Sackl, but he's away until the 16th, so there won't be a lot of movement on this for a bit.)
Flags: needinfo?(bwinton)
Flags: needinfo?(philipp)
(In reply to Blake Winton (:bwinton) (:☕️) from comment #3) > (I've asked Philipp Sackl, but he's away until the 16th, so there won't be a > lot of movement on this for a bit.) Any update?
Flags: needinfo?(bwinton)
Looked at this together with Blake today. Since this UI matches the OS-level UI more closely, it seems to be a good choice. However, let's only enable it for new profiles, since I'm sure there is a small but active group of users who's workflow would be negatively impacted if we just changed the pref for them. We can always selectively nudge existing profiles towards it later once we have CFR.
Flags: needinfo?(philipp)
Flags: needinfo?(bwinton)
Assignee: nobody → dao+bmo
Status: NEW → ASSIGNED
status-firefox62: affected → wontfix
Summary: Set `browser.ctrlTab.previews` to true by default. → Enable "Ctrl+Tab cycles through tabs in recently used order" feature by default in new profiles
Attachment #8994576 - Flags: review?(jaws)
Comment on attachment 8994576 [details] Bug 1473595 - Enable "Ctrl+Tab cycles through tabs in recently used order" feature by default in new profiles. https://reviewboard.mozilla.org/r/259118/#review266478 Should we fix bug 1289395 now that the feature is getting enabled?
Attachment #8994576 - Flags: review?(jaws) → review+
I would say "Probably, yeah"… :)
We're sorry, Autoland could not rebase your commits for you automatically. Please manually rebase your commits and try again. hg error in cmd: hg rebase -s 792ef8a28638227295f81ee3344da7ccd0fd778d -d bc3f6f7249ed: rebasing 474623:792ef8a28638 "Bug 1473595 - Enable "Ctrl+Tab cycles through tabs in recently used order" feature by default in new profiles. r=jaws" (tip) merging browser/app/profile/firefox.js merging browser/components/nsBrowserGlue.js warning: conflicts while merging browser/components/nsBrowserGlue.js! (edit, then use 'hg resolve --mark') unresolved conflicts (see hg resolve, then hg rebase --continue)
Pushed by dgottwald@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/a3140755de69 Enable "Ctrl+Tab cycles through tabs in recently used order" feature by default in new profiles. r=jaws
See Also: → ctrl-tab-panel
relnote-firefox: --- → ?
Backed out for debug-mochitest-chrome failures on test_key_event_counts.xul and test_htmleditor_keyevent_handling.html. Backout link: https://hg.mozilla.org/integration/autoland/rev/784b3787669f60c9302d475cbbbf6b4c2a094300 Push link: https://hg.mozilla.org/integration/autoland/rev/a3140755de6987e9e383f128a5e56386a6da0b09 Log link for test_htmleditor_keyevent_handling.html : https://treeherder.mozilla.org/logviewer.html#?job_id=190226514&repo=autoland&lineNumber=14010 Log link for test_key_event_counts.xul: https://treeherder.mozilla.org/logviewer.html#?job_id=190224296&repo=autoland&lineNumber=19495
Flags: needinfo?(dao+bmo)
Depends on: 1478646
Flags: needinfo?(dao+bmo)
Pushed by dgottwald@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/9fe3f733a48a Enable "Ctrl+Tab cycles through tabs in recently used order" feature by default in new profiles. r=jaws
https://hg.mozilla.org/mozilla-central/rev/9fe3f733a48a
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
status-firefox63: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 63
Added to Nightly release notes in the "Changed" section with this wording: The Ctrl+Tab shortcut now displays thumbnail previews of your tabs and cycles through tabs in recently used order. This new default behavior is activated only in new profiles and can be changed in your preferences
relnote-firefox: ? → 63+
Depends on: 1481321
I have reproduced this bug with Nightly 63.0a1 (2018-07-05) on Windows 10, 64 Bit! This bug's fix is verified with latest Nightly! Build ID 20180811220142 User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0
QA Whiteboard: [bugday-20180808]
Status: RESOLVED → VERIFIED
status-firefox63: fixed → verified
No longer depends on: 1488168
Do I understand correctly that the recently-used setting also controls whether the alt-tab-like screen is used at all? This took me a long time to figure out. (I wanted the old setting back in order to do some memory testing and have ctrl+tab+tab+tab... make sure all my pages were warm, and I ignored this checkbox in preferences because it seemed unrelated.)
(In reply to David Major [:dmajor] from comment #18) > Do I understand correctly that the recently-used setting also controls > whether the alt-tab-like screen is used at all? Indeed! Since the MRU ordering requires an additional visual queue to determine which tab you're about to navigate to, whereas the tabstrip order is already quite clear.
Hi, I agree this is a very handy function and nice UI (I use it all the time), but have you taken (1) accessibility and (2) consistency into account? (1) I can imagine that users which have limited ability to use the mouse heavily rely on Ctrl+Tab to cycle through tabs in the tabstrip order (https://support.mozilla.org/en-US/kb/accessibility-features-firefox-make-firefox-and-we)? Not speaking from personal experience, so not entirely sure about this ... (2) Moreover, this is a keyboard shortcut that is shared by other browsers (https://www.howtogeek.com/114518/47-keyboard-shortcuts-that-work-in-all-web-browsers/), so *especially* new users may expect this shortcut to work in the same way as in Chrome, IE and others! So maybe this shouldn't be the default setting after all, but instead being promoted as a handy function in an other way (e.g. optional 'Tips & tricks' feature which helps user discover interesting features such as this one)? Thanks for reading.
(In reply to Ruben from comment #20) > I agree this is a very handy function and nice UI (I use it all the time), > but have you taken (1) accessibility and (2) consistency into account? Yes. ;) > (1) I can imagine that users which have limited ability to use the mouse > heavily rely on Ctrl+Tab to cycle through tabs in the tabstrip order > (https://support.mozilla.org/en-US/kb/accessibility-features-firefox-make- > firefox-and-we)? Not speaking from personal experience, so not entirely sure > about this ... Ctrl-PgUp/PgDn (Ctrl-[/Ctrl-] on Mac) will still move through the tabs in visual order, so while this may require some practice, it does not remove any functionality. > (2) Moreover, this is a keyboard shortcut that is shared by other browsers > (https://www.howtogeek.com/114518/47-keyboard-shortcuts-that-work-in-all-web- > browsers/), so *especially* new users may expect this shortcut to work in > the same way as in Chrome, IE and others! MRU switching should be very familiar from the operating system they use, and could even be considered a distinguishing feature causing them to *prefer* Firefox! :) While consistency with other browsers is a consideration, it's not the only considerration, and since this is consistent with the OS, I don't see this as a huge problem which needs mitigating. Thank you for your questions!
It is indeed consistent with application switching on Windows and Mac. And you can still disable it if you want to use Ctrl+Tab for switching in visual order. Ctrl-PgUp/PgDn also works in the same way in Firefox, Chrome, Edge ... didn't know about that one. Thank you for the clarification!
I don't mean to be discouraging but this is a horrible default. Ctrl-Tab in a browser has the universal meaning of "switch to next tab in the tab strip". Ctrl-Shift-Tab does the opposite. (In reply to Blake Winton (:bwinton) (:☕️) from comment #21) > (In reply to Ruben from comment #20) > > Ctrl-PgUp/PgDn (Ctrl-[/Ctrl-] on Mac) will still move through the tabs in > visual order, so while this may require some practice, it does not remove > any functionality. I have to create fresh firefox profiles often and it is extremely annoying to have to switch the preference off first every single time I create a new profile, just so I could switch tabs properly. > MRU switching should be very familiar from the operating system they use, > and could even be considered a distinguishing feature causing them to > *prefer* Firefox! :) While consistency with other browsers is a > consideration, it's not the only considerration, and since this is > consistent with the OS, I don't see this as a huge problem which needs > mitigating. If consistency with the OS is your motivation, then this should be disabled for Linux machines at least. I don't know what distro or desktop environment this was tested on, or if it even was tested on Linux at all, but right now Firefox is inconsistent with both - the OS *and* other browsers.
I noticed two problems with this new feature. First, all the other browsers have a different behavior for Control-Tab. I understand the OS behavior is based on MRU apps, but for whatever reason, I found the new behavior to be highly unintuitive. I concur with awalgarg, this is a very counterintuitive default in a browser. Every other browser I've ever used has this exactly backwards. Second, the switch to the last-used tab is much slower than the next tab/forward tab functionality. I think this is due to tab previews being generated/drawn, but that's me conjecturing. I recommend a reconsideration of your defaults, or at a minimum for the speed issue to be addressed. This seems to be less a feature and more a regression IMO.
(In reply to greg from comment #24) > Second, the switch to the last-used tab is much slower than the next > tab/forward tab functionality. I think this is due to tab previews being > generated/drawn, but that's me conjecturing. The previews actually show up with a small delay, so you can quickly switch to the last used tab without them even showing.
On Fedora 29 and a new profile on Firefox 63, I need to press Enter to validate the tab and make the preview disappear. Is this the expected behavior, or I should open a new issue?
(In reply to baptiste.darthenay from comment #26) > On Fedora 29 and a new profile on Firefox 63, I need to press Enter to > validate the tab and make the preview disappear. Is this the expected > behavior, or I should open a new issue? Not expected... please file a bug. Thanks!
Depends on: 1505947
Blocks: 1506037
(In reply to greg from comment #24) > Second, the switch to the last-used tab is much slower than the next > tab/forward tab functionality. I think this is due to tab previews being > generated/drawn, but that's me conjecturing. > > I recommend a reconsideration of your defaults, or at a minimum for the > speed issue to be addressed. This seems to be less a feature and more a > regression IMO. On a quad core Dell 9550, there is sufficient visual lag during rendering that at first I thought I had triggered some OEM junkware popup on this laptop, which is compounded by the lack of visual consistency with the remainder of the browser. For a change that introduces such huge latency to a core tabbed browsing feature in the browser that originally brought tabbed browsing to the masses, I'm really surprised this was merged as-is. The feature introduces an unavoidable 100-200ms latency on switching between tabs. On the assumption that at some point the new default will become mandatory, it seems some re-engineering is absolutely required to remove the lag. Is this time spent generating previews on the fly? Perhaps that could be punted to a background task. Is it time spent constructing the pop-up? Perhaps it can exist as a hidden window, etc.
(In reply to dw from comment #28) > The feature introduces an unavoidable 100-200ms latency on switching between > tabs. No, it does not. As I said in comment 25, you can switch tabs by releasing Ctrl+Tab before the panel shows up. This is intentional; we don't want to show the panel when the user is just switching back and forth between two tabs.
(In reply to Dão Gottwald [::dao] from comment #29) > (In reply to dw from comment #28) > > The feature introduces an unavoidable 100-200ms latency on switching between > > tabs. > > No, it does not. As I said in comment 25, you can switch tabs by releasing > Ctrl+Tab before the panel shows up. This is intentional; we don't want to > show the panel when the user is just switching back and forth between two > tabs. As there is no longer a permanent visual indication of tab order, the popup is essentially required for the feature to work at all. Therefore for users with things to do beyond memorizing their browser tab order, the delay is mandatory.
The delay is only present when hitting Ctrl+Tab once. When hitting it twice the panel shows up immediately. The rationale is that the user likely remembers the last used tab without a preview.
(In reply to Dão Gottwald [::dao] from comment #31) > The delay is only present when hitting Ctrl+Tab once. When hitting it twice > the panel shows up immediately. The rationale is that the user likely > remembers the last used tab without a preview. Thanks for sharing this, I can confirm double-tapping Ctrl+Tab indeed renders the UI instantly. To be clear, I understand this feature aims to address a real problem. So it seems the lag is entirely artificial -- is there any chance of exposing the timeout at the very least as a pref? The introduction of an intentional artificial delay into a previously instantaneous core browser action would seem to contradict everything our industry has come to understand about UI latency over the past 3 decades. I'm happy to open a separate bug to track this and include references to related research, but per user comments here, my snap judgement of the feature in #1505947, and typical user expectation, it seems it would already be fair to expect a perpetual stream of new bug reports as users replace their profiles while they delay remains.
(In reply to Dão Gottwald [::dao] from comment #29) > No, it does not. As I said in comment 25, you can switch tabs by releasing > Ctrl+Tab before the panel shows up. This is intentional; we don't want to > show the panel when the user is just switching back and forth between two > tabs. (In reply to Dão Gottwald [::dao] from comment #31) > The delay is only present when hitting Ctrl+Tab once. When hitting it twice > the panel shows up immediately. The rationale is that the user likely > remembers the last used tab without a preview. How do we communicate these to surprised/frustrated users? Especially the ones who don't know to come to hg, Bugzilla, or the release notes. I see in this bug a number of well-intended reasons for the technical characteristics of this feature, but ultimately, if users have a bad experience, the product suffers despite the intentions.
(In reply to dw from comment #32) > So it seems the lag is entirely artificial -- is there any chance of > exposing the timeout at the very least as a pref? You mean a hidden about:config pref or a visible about:preferences one? Hidden prefs are generally not the best way to address UX issues, since they're pretty much inaccessible to average users. On the other hand, this is probably not important enough to be added to about:preferences. > The introduction of an > intentional artificial delay into a previously instantaneous core browser > action would seem to contradict everything our industry has come to > understand about UI latency over the past 3 decades. A similar delay is actually used by some windows managers for Alt+Tab... (In reply to David Major [:dmajor] from comment #33) > How do we communicate these to surprised/frustrated users? Especially the > ones who don't know to come to hg, Bugzilla, or the release notes. support.mozilla.org?
I suggest three things: 1. Questions as these (https://support.mozilla.org/en-US/questions/1239149) make it clear that users don't find the setting to enable/disable the tab previews (which go together with the MRU setting). Therefore, the setting label "Ctrl+Tab cycles through tabs in recently used order" could be adapted to "Ctrl+Tab cycles through tabs in recently used order (with tab previews)". This aligns with the other available setting "Show tab previews in the Windows taskbar". Notice the brackets, as tab previews are not *always* shown. 2. A *separate* SUMO Help article to explain in full detail how tab switching works in Firefox, and what options are available. This page should at least include the info from comment 29 and comment 31. 3. Revise SUMO Help – Keyboard Shortcuts (bug 1506037).
(In reply to Dão Gottwald [::dao] from comment #34) > A similar delay is actually used by some windows managers for Alt+Tab... To my knowledge and experience, no major desktop OS behaves this way, certainly not OS X or Windows (although this *is* a tweaked Windows install). Regarding precedent for troubles caused by introducing delays on keyboard actions, refer to e.g. the Office 2013 debacle where a mandatory animation was introduced moving between cells on an Excel worksheet, that ended with an update issued to make the behavior optional. I'll stop following up now, thanks again for your replies. It'll be fun to watch what happens in time as the new behavior is exposed to a wider audience.
Flags: needinfo?(philipp)
> However, let's only enable it for new profiles, since I'm sure there is a small but active group of users who's workflow would be negatively impacted if we just changed the pref for them. Another way of approaching this is to run a pref-flip study (https://wiki.mozilla.org/Firefox/Shield#Supported_Study_and_Messaging_Designs) with a follow-up reactions/satisfaction survey on a selected part of the Firefox population. > We can always selectively nudge existing profiles towards it later once we have CFR. No need to wait for CFR. You can approach this today either with a Heartbeat prompt targeting the migrated profiles or, to be able to more closely observe changed behavior regarding tab switching, an Add-on Based Study. A rollout preference study may also be relevant for more widespread enabling of this as the default behavior.
Also confusing about this change is that Ctrl+Shift+Tab now does nothing -- unless Ctrl+Tab was pressed and the popup is still open. Previously it immediately switched tabs, so at first, I thought tab switching was broken entirely. Note that since tabs are added to the end, it might be that users use Ctrl+Shift+Tab more frequently than Ctrl+Tab. PS: For anyone who wants to revert to old behavior, toggle "browser.ctrlTab.recentlyUsedOrder" in about:config. Seems this wasn't mentioned anywhere in this discussion.
(In reply to Marti Raudsepp from comment #40) > PS: For anyone who wants to revert to old behavior, toggle > "browser.ctrlTab.recentlyUsedOrder" in about:config. Seems this wasn't > mentioned anywhere in this discussion. It's exposed in about:preferences as "Ctrl+Tab cycles through tabs in recently used order".
Regressions: 1661996
Depends on: 1661996
No longer regressions: 1661996
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: