Closed Bug 571992 Opened 9 years ago Closed 9 years ago

Switch Tabs-on-top to be the Default State on Windows

Categories

(Firefox :: Tabbed Browser, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 4.0b1
Tracking Status
blocking2.0 --- beta1+

People

(Reporter: shorlander, Assigned: dao)

References

Details

Attachments

(1 file, 1 obsolete file)

Change tabs to be on top by default for Firefox 4 Beta 1.
blocking2.0: --- → ?
The UX team would like to release a video simultaneously with this change.  Before anyone checks this in for the nighties please confirm in this bug that the video has been posted (should be Tuesday or Wednesday).
Depends on: 572112
Not sure that bug 572112 is a dependency, but it's a Firefox 4 blocker for sure.
I think they're completely independent (though I agree that bug should be fixed).
No longer depends on: 572112
Attached patch Patch v1 (obsolete) — Splinter Review
Assignee: nobody → supernova00
Status: NEW → ASSIGNED
Attachment #451292 - Flags: review?(dao)
Comment on attachment 451292 [details] [diff] [review]
Patch v1

What you really need to do is set the tabsontop attribute on the toolbox.

I think we can't do this on Linux yet, as it looks unreasonable. Not sure about OS X.
Attachment #451292 - Flags: review?(dao) → review-
Flags: in-litmus?
(In reply to comment #5)
> (From update of attachment 451292 [details] [diff] [review])
> What you really need to do is set the tabsontop attribute on the toolbox.
> 
> I think we can't do this on Linux yet, as it looks unreasonable. Not sure about
> OS X.

I don't think this will work on OS X until bug #562733 lands.

Hi Kurt, are you planning on updating the patch to address Dao's comments? Thanks!
I'm hoping we can do this per-platform as the rest of the theme work comes in to support it. To start we'd like to do it on Windows only - re summarizing.
Summary: Switch Tabs-on-top to be the Default State → Switch Tabs-on-top to be the Default State on Windows
Attached patch patchSplinter Review
Assignee: supernova00 → dao
Attachment #451292 - Attachment is obsolete: true
Attachment #453038 - Flags: review?(gavin.sharp)
Blocks: 544820
No longer blocks: 544823
blocking2.0: ? → beta1+
Let's flip the pref for windows now.  The post is planned to go out on Friday evening, but it will be up before we ship the beta.
Attachment #453038 - Flags: review?(gavin.sharp) → review+
Keywords: checkin-needed
I'd like to make sure that the post is up before we flip it in nightlies, tbqh. Can we get the post up tonight?
(In reply to comment #10)
> I'd like to make sure that the post is up before we flip it in nightlies, tbqh.
> Can we get the post up tonight?
Hopefully that goes up today since I just pushed this...

http://hg.mozilla.org/mozilla-central/rev/88142593698a
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.7a6
I actually landed this just a bit earlier: http://hg.mozilla.org/mozilla-central/rev/4a6f3d15cfdc
http://hg.mozilla.org/mozilla-central/rev/88142593698a is going to cause an XML error, I think...
(In reply to comment #12)
> I actually landed this just a bit earlier:
> http://hg.mozilla.org/mozilla-central/rev/4a6f3d15cfdc
> http://hg.mozilla.org/mozilla-central/rev/88142593698a is going to cause an XML
> error, I think...
So, why was it checkin-needed then, and why didn't I get conflicts when applying it?
Backed out my push.  In the future, please unmark checkin-needed on bugs you land so others don't have to waste time landing and then possibly backing it out.

http://hg.mozilla.org/mozilla-central/rev/39cb8075f844
http://hg.mozilla.org/mozilla-central/rev/945351318494
>I'd like to make sure that the post is up before we flip it in nightlies, tbqh.
>Can we get the post up tonight?

video and mockups are now up:
http://blog.mozilla.com/faaborg/2010/06/24/why-tabs-are-on-top-in-firefox-4/
Depends on: 574593
Here's the official(?) feedback page for the new features in Firefox 4:
http://firefox.uservoice.com/forums/57440-firefox-4-beta

Not much feedback there yet. Perhaps that page needs to be promoted better.
Is it expected that the bookmarks toolbar is disabled, even with a new profile? I have to explicitly enable it if I want it shown.
(In reply to comment #18)
> Is it expected that the bookmarks toolbar is disabled, even with a new profile?
> I have to explicitly enable it if I want it shown.

That is intended.
(In reply to comment #18)
> Is it expected that the bookmarks toolbar is disabled, even with a new profile?
> I have to explicitly enable it if I want it shown.

Yes, that was done in bug 544817
Depends on: 574739
(In reply to comment #18)
> Is it expected that the bookmarks toolbar is disabled, even with a new profile?
> I have to explicitly enable it if I want it shown.

The bookmarks toolbar is disabled only in new profile and in profile with untouched toolbar.
(In reply to comment #21)
> The bookmarks toolbar is disabled only in new profile and in profile with
> untouched toolbar.

So the millions of users who have touched their Bookmarks Toolbar will have to live with the problems identified here http://blog.mozilla.com/faaborg/2010/06/24/why-tabs-are-on-top-in-firefox-4/comment-page-1/#comment-159018 and/or here http://firefox.uservoice.com/forums/57440-firefox-4-beta/suggestions/842641-tabs-above-page-bookmarks-toolbar-ugly-please?ref=title

BTW: Where was the discussion of the pros and cons on dropping the Bookmarks Toolbar? It is IMO a very important part of the UI that deserved and needed love and care (i.e. evolving) instead of back-burner status (i.e. hidden and thus likely forgotten).

(sorry for the slightly OT subject, but in the current context this seems the best place to bring it up at the moment)
I'm using tabs on top with bookmarks bar longer than this landed and I don't have any problem. So the millions of users minus me who have touched their Bookmarks Toolbar will have to live with the problems.
The bookmarks toolbar change is lower impact because it doesn't modify existing profiles that are using it (well, once we get the detection implemented correctly).  Since a large number of users never interacted with it, we give them some screen space back.
(In reply to comment #24)
> The bookmarks toolbar change is lower impact because it doesn't modify existing
> profiles that are using it (well, once we get the detection implemented
> correctly).

You might want to blog about that, FWIW, as it'll bite all Beta 1 users. Can you also add the "relnote" keyword to that bug?
I'll mention it in the UI video, also added the relnote keyword to bug 574514
Depends on: 576807
Verified fixed with 

Dao, is that change covered in some way by brower-chrome tests?
Status: RESOLVED → VERIFIED
Nope, there's nothing interesting to test here.
Flags: in-testsuite-
Depends on: 577820
No longer depends on: 577820
https://litmus.mozilla.org/show_test.cgi?id=12064 covers this in Litmus.
Flags: in-litmus? → in-litmus+
Depends on: 590867
You need to log in before you can comment on or make changes to this bug.