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

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

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

Comment 1

[Jennifer Morrow [:Boriss] (UX)]

    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

Comment 2

[Tony Chung [:tchung]]

flagging in-litmus? as a reminder to temporarily disable these testcases that marcia has written.

Comment 3

[Marcia Knous [:marcia]]

Test cases have been disabled in Litmus.

Comment 4

[u88484]

Can't it just be polished in the RC?  That is usually when things are polished anyways.

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 6

[Mike Connor [:mconnor]]

Attachment: wip

Comment 7

[Mike Connor [:mconnor]]

Attachment: more

Comment 8

[Mike Connor [:mconnor]]

Attachment: with more cowbell^Wpreprocessor

Comment 9

[Mike Connor [:mconnor]]

Comment on attachment 349126 [details] [diff] [review]
with more cowbell^Wpreprocessor

Sanity checking!

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

Any way we can get this landed in time for nightlies? If not, please tell #build to clobber and respin nightlies after it lands.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Pushed http://hg.mozlla.org/mozilla-central/rev/028bbc611036

Comment 12

[Shawn Wilsher :sdwilsh]

We've got orange going across the tree from this.  Did *anyone* run the tests on this to make sure they all still pass?

Comment 13

[Shawn Wilsher :sdwilsh]

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

Comment 14

[Mike Beltzner [:beltzner, not reading bugmail]]

Dao - if you're around, can you take a look and see what tests are failing and what's causing that? Here are some build logs:

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1227202603.1227206117.15744.gz

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1227203615.1227207346.19112.gz

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1227203233.1227206687.17419.gz

Comment 15

[Mike Connor [:mconnor]]

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.

Comment 16

[eyal gruss]

although the UI is being backed out, is it possible to keep the functionality that ctrl-tab uses MRU order?

Comment 17

[eyal gruss]

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?

Comment 18

[Peter Lairo]

(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.

Comment 19

[Marcia Knous [:marcia]]

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.

Comment 20

[Nochum Sossonko [:Natch]]

removing fixed1.9.1 b/c these bugs are verified1.9.1, sorry for the spam.