Closed Bug 465843 Opened 11 years ago Closed 11 years ago

remove ctrl-tab preview switching and revert all tabs button to menu (for now!)

Categories

(Firefox :: Tabbed Browser, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 3.1b2

People

(Reporter: beltzner, Assigned: mconnor)

References

Details

(Keywords: verified1.9.1)

Attachments

(1 file, 2 obsolete files)

The interaction model and visual design for the new "Ctrl-Tab" and "All Tabs" isn't fully polished or worked out. Instead of including it in what's to be the last beta for Firefox 3.1, it seems more sensible to:

 - back it out for beta 2
 - land it on trunk once we branch for 3.1
 - quickly iterate on trunk and with tryserver builds
 - if we get it feeling right, we can take it back
 - if not, we can get it right in the next release
Flags: blocking-firefox3.1+
    Just wanted to add that this is the summary of discussion we've been having re
    where Ctrl+Tab is and what can be done for 3.1.  The situation right now is
    still risky - there's bugs in Ctrl+Tab, unresolved issues, and frankly not the
    level of polish we'd like in 3.1.  

    More details about where things are and what questions remain are at the wiki:
    https://wiki.mozilla.org/Firefox3.1/control_tab
flagging in-litmus? as a reminder to temporarily disable these testcases that marcia has written.
Flags: in-litmus?
Test cases have been disabled in Litmus.
Flags: in-litmus? → in-litmus+
Can't it just be polished in the RC?  That is usually when things are polished anyways.
That's when things have usually been polished when there are a small number of outlying issues which are understood & assigned. The issue here is that we keep discovering additional issues, there's a good amount of visual polish that's TBD, and the interaction model doesn't feel quite right yet.

We're trying to do things differently with this release and ensure that we don't have things in flight that aren't quite ready; since we're hitting the last beta and we (being Dao, Boriss, Connor and myself, the primary drivers of this feature) don't feel confident at this time, this seems the most sensible course of action.
Summary: remove ctrl-tab preview switching and all tabs button (for now!) → remove ctrl-tab preview switching and revert all tabs button to menu (for now!)
Attached patch wip (obsolete) — Splinter Review
Attached patch more (obsolete) — Splinter Review
Attachment #349118 - Attachment is obsolete: true
Attachment #349119 - Attachment is obsolete: true
Comment on attachment 349126 [details] [diff] [review]
with more cowbell^Wpreprocessor

Sanity checking!
Attachment #349126 - Flags: review?(gavin.sharp)
Attachment #349126 - Flags: review?(gavin.sharp) → review?(dao)
Attachment #349126 - Flags: review?(dao) → review+
Whiteboard: [needs landing]
Any way we can get this landed in time for nightlies? If not, please tell #build to clobber and respin nightlies after it lands.
Pushed http://hg.mozlla.org/mozilla-central/rev/028bbc611036
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
We've got orange going across the tree from this.  Did *anyone* run the tests on this to make sure they all still pass?
I was going to try and fix it, but there are a lot of changes to that file (http://hg.mozilla.org/mozilla-central/log/tip/browser/base/content/test/browser_ctrlTab.js) with all taps/ ctrl tab, so I disabled the test.  Someone please fix this...

http://hg.mozilla.org/mozilla-central/rev/5b81a5dc7485
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
These tests were designed for the new behaviour.  As we're simply temporarily disabling the new behaviour, it doesn't make sense to change the tests to test the old behaviour, this is akin to a straight backout.  The tests are currently disabled, which is fine, because the feature they're testing is disabled.

Re-resolving.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
although the UI is being backed out, is it possible to keep the functionality that ctrl-tab uses MRU order?
i feel that the most important feature of ctrl-tab is to allow switching back and forth between two tabs. with the current patch beta 2 is regression in functionality from beta 1, and users may decide to stick with beta 1.
if we decide to retain MRU order in beta 2, there are two possibilities:
1. carry over the 3.1 beta 1 implementation
2. no UI, just use MRU order instead of tab order

should i open a new bug for this?
(In reply to comment #17)
> i feel that the most important feature of ctrl-tab is to allow switching back
> and forth between two tabs. 

That may be the case when there are only two tabs present anyhow, so no MRU is needed there. And when there are more than two tabs, then I think the user is at least just as likely to want to switch between all those tabs, thus making MRU a burdensome complexity on top of the already visually recognizable tab order.
verified fixed using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081121 Minefield/3.1b2pre, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081121 Minefield/3.1b2pre, Windows Vista and Linux equivalents.
Status: RESOLVED → VERIFIED
Whiteboard: [needs landing]
Depends on: 472740
Depends on: 467853
Keywords: verified1.9.1
removing fixed1.9.1 b/c these bugs are verified1.9.1, sorry for the spam.
Keywords: fixed1.9.1
You need to log in before you can comment on or make changes to this bug.