New tab and toolbar style for Linux

RESOLVED FIXED in Firefox 4.0b7

Status

()

--
enhancement
RESOLVED FIXED
9 years ago
7 years ago

People

(Reporter: shorlander, Assigned: dao)

Tracking

Trunk
Firefox 4.0b7
All
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(5 attachments, 2 obsolete attachments)

(Reporter)

Description

9 years ago
Created attachment 451664 [details]
New Tab Style

New tab style for Linux:

* Active Tab + Toolbar Backgrounds - Overlay white highlight gradient, edge effects, borders and shadows on using base window color.

* Inactive Tab - Use window color at -20% luminance and saturation and 90% opacity. Alternatively get GTK theme inactive tab color at 90% opacity. Overlay gradients, edge effects, borders and shadows. Another possibility would be to use ThreeDShadow as a base color with gradient overlays.
(Reporter)

Updated

9 years ago
Blocks: 572482
That style is simple yet very beautiful. While not GTK-look anymore, I strongly support going for this style, as it does a lot to unify the look of Firefox across platforms and also hints that the tabs work like Firefox tabs (not GTK tabs). As we still pick up the GTK theme colors, things will still "fit in" IMHO.

Also, this will solve the problems we would run into with bug #544818 (progress bars)
I just compared the tabbox.css files if winstripe and gnomestripe... do we need a new -moz-appearance for this style?

Currently "tab" is used on both platforms with totally different results. Maybe we could have "tab" as in "Firefox look" and tab-native for "GTK look"?
Stephen, I have not yet seen a bug about this but if we go for the new tabs and toolbars (even if not...), can we please also go for a flat toolbox background as well? You seem to use this in all of the mockups and it just looks *so* much better than what we have right now...
(Reporter)

Comment 4

9 years ago
(In reply to comment #2)
> I just compared the tabbox.css files if winstripe and gnomestripe... do we need
> a new -moz-appearance for this style?
> 
> Currently "tab" is used on both platforms with totally different results. Maybe
> we could have "tab" as in "Firefox look" and tab-native for "GTK look"?

I don't think we need a new -moz-appearance style. On windows/mac we just specify the CSS rules for tabs in the main window.

(In reply to comment #3)
> Stephen, I have not yet seen a bug about this but if we go for the new tabs and
> toolbars (even if not...), can we please also go for a flat toolbox background
> as well? You seem to use this in all of the mockups and it just looks *so* much
> better than what we have right now...

Michael, by "flat" do you mean extending the titlebar color behind the tabs as well?
Created attachment 457998 [details]
Current vs Flat

>> Michael, by "flat" do you mean extending the titlebar color 
>> behind the tabs as well?

No, as we don't currently have a way to do this. What I mean is basicly getting rid of all those lines (see screenshot).

Some GTK themes (murrine based?) actually do this but other themes (clearlooks etc) profit from this as well. Besides showing less clutter, we don't end up with a bright gray line just below the tabs (tabs on top with clearlooks) for example.
(In reply to comment #4)
> I don't think we need a new -moz-appearance style. On windows/mac we just
> specify the CSS rules for tabs in the main window.

Hmm... I had a look at the win/mac themes but I guess I did not find the changes in question here. Anyone working on this for Linux yet?
(Reporter)

Comment 7

9 years ago
(In reply to comment #6)
> Anyone working on this for Linux yet?

I don't think anyone is working on any of the Linux bugs yet.
(Assignee)

Comment 8

9 years ago
I think we can port this pretty easily from winstripe once that's polished up.
(Reporter)

Comment 9

9 years ago
(In reply to comment #8)
> I think we can port this pretty easily from winstripe once that's polished up.

That would be great!
(In reply to comment #9)
> (In reply to comment #8)
> > I think we can port this pretty easily from winstripe once that's polished up.
> 
> That would be great!

Is there a specific winstripe bug we should block this one on?
(Assignee)

Comment 11

8 years ago
(In reply to comment #10)
> Is there a specific winstripe bug we should block this one on?

No specific one, no.
(Assignee)

Comment 12

8 years ago
Created attachment 470765 [details] [diff] [review]
patch
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #470765 - Flags: review?(gavin.sharp)
(Assignee)

Updated

8 years ago
Summary: [Linux] New Tab Style → New tab and toolbar style for Linux
(Assignee)

Comment 13

8 years ago
Created attachment 470778 [details] [diff] [review]
patch

just tweaked the textures a bit
Attachment #470765 - Attachment is obsolete: true
Attachment #470778 - Flags: review?(gavin.sharp)
Attachment #470765 - Flags: review?(gavin.sharp)
(Assignee)

Updated

8 years ago
Blocks: 592265
(Assignee)

Updated

8 years ago
No longer blocks: 592265
(In reply to comment #12)
> patch

Beautiful!

There seems to be one small bug: fill up the whole bar with tabs and check the top border of the last tab(s). Seems to be a missing pixel either at the left or right top corner.

Also, the mockups¹ don't use GTK icons for "close" and "newtab". I kind of like the light look of the close icon on the mockup compared to the heavy looking GTK close button which is currently being used.

[1] https://wiki.mozilla.org/Firefox/4.0_Linux_Theme_Mockups
(Assignee)

Comment 15

8 years ago
(In reply to comment #14)
> There seems to be one small bug: fill up the whole bar with tabs and check the
> top border of the last tab(s). Seems to be a missing pixel either at the left
> or right top corner.

I've seen this, pretty sure we're hitting a platform bug here.

> Also, the mockups¹ don't use GTK icons for "close" and "newtab".

Could be taken care of in a follow-up bug.
>> Could be taken care of in a follow-up bug.
Sure.

Two more things:

- the tab outline and inactive tab background should be a bit darker I think (compare the Clearlooks mockup to actual Firefox+Patch+Clearlooks)

- the mocked up tabs seem to be 23px high while with the patch I get 27px. Is this depending on font size etc or hardcoded? To me the text label looks a bit too high... Anyway, it should match other platforms.
(Assignee)

Comment 17

8 years ago
The tab height depends on the font size as well as the close button.
Created attachment 470804 [details]
Clearlooks menubar with and without line

>> The tab height depends on the font size as well as the close button.
Ok, just another reason to go for a simple cross-platform "x" instead of the heavy button.

Just one more thing: the menubar is still not "flat". In Clearlooks, it "just" draws a line between menu and toolbars which however looks bad especially with tabs on top. Other themes even draw real boxes around the whole menubar. A -moz-appearance: none on the menubar should solve the problem I think and bring us another step closer to the mockup.
(Assignee)

Comment 19

8 years ago
(In reply to comment #18)
> Just one more thing: the menubar is still not "flat". In Clearlooks, it "just"
> draws a line between menu and toolbars which however looks bad especially with
> tabs on top. Other themes even draw real boxes around the whole menubar. A
> -moz-appearance: none on the menubar should solve the problem I think and bring
> us another step closer to the mockup.

It would actually regress the menu bar appearance for various gtk themes (i.e. those that connect the menu bar with the title bar).
(Assignee)

Comment 20

8 years ago
(In reply to comment #15)
> (In reply to comment #14)
> > There seems to be one small bug: fill up the whole bar with tabs and check the
> > top border of the last tab(s). Seems to be a missing pixel either at the left
> > or right top corner.
> 
> I've seen this, pretty sure we're hitting a platform bug here.

Bug 422179 fixes this.
(Assignee)

Comment 21

8 years ago
Created attachment 471617 [details] [diff] [review]
patch

updated to tip
Attachment #470778 - Attachment is obsolete: true
Attachment #471617 - Flags: review?(gavin.sharp)
Attachment #470778 - Flags: review?(gavin.sharp)
Attachment #471617 - Flags: review?(gavin.sharp) → review+
(Assignee)

Updated

8 years ago
Blocks: 593382
(Assignee)

Comment 22

8 years ago
http://hg.mozilla.org/mozilla-central/rev/19cd237c24b0
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b6
Depends on: 593569
(Assignee)

Updated

8 years ago
Depends on: 593570
Blocks: 579373
(Assignee)

Updated

8 years ago
No longer blocks: 579373

Comment 23

8 years ago
Thank you Dão, the improvements are great. :)

On the related topic of tabs on top, when is that going to be flipped on by default for Linux? I thought this bug covered that under the category of "tab style" but I guess not. Does a bug for toggling the default pref need filing?
(In reply to comment #23)
> Does a bug for toggling the default pref need filing?

Yes.. iirc we agreed to go tabs on top by default on linux even without firefox button etc
(Assignee)

Updated

8 years ago
Blocks: 593477
(Assignee)

Updated

8 years ago
Depends on: 593650
In the latest build, I saw changes for the tab style and the combined stop/go/refresh button in the location appearing.

The tab look is great even if it's sort of strange to have a gradient because my GTK theme is flat. Anyway you can not adapt to all themes in the world :)

I do not know how to report this, but opening and closing a tab animation speed has regressed a lot though :/ I've got an old computer : Centrino 1.6 on latest F14, but before those 2 changes (tab style + location bar), the animation was extremely smooth.

Now it's sluggish : I've got something like 3 different frames drawn when I add a tab, and same when I close one. Switching tab seems slower, but that might be a perceived effect.

It seems this is due to drawing the new tab style, but I am not so sure since some performance regression was spotted after location bar landed the first time...

Do I need to file a bug against the new tab style? Do I even need to open one and this is known and will be fixed later?

thanks for all the hard work over the years ;)
(In reply to comment #25)
> I do not know how to report this, but opening and closing a tab 
> animation speed has regressed a lot though :/ I've got an old 
> computer : Centrino 1.6 on latest F14

That is strange...for me, the animation actually seems to be much smoother *now*... are you sure the problem started with this build and not some Fedora specific update? You are running a pre-beta distribution after all... Is Firefox the only app that shows performance losses?
(Assignee)

Comment 27

8 years ago
(In reply to comment #25)
> It seems this is due to drawing the new tab style, but I am not so sure since
> some performance regression was spotted after location bar landed the first
> time...
> 
> Do I need to file a bug against the new tab style? Do I even need to open one
> and this is known and will be fixed later?

You'll need to file a bug, and it would be helpful if you could identity the last good / first bad builds from http://hourly-archive.localgho.st/hourly-archive2/mozilla-central-linux/.
Michael: I forgot to stay reverting to beta 5 was 100% smooth again.
Dão: thanks I did not know about that hourly build. I found the time frame so I opened #593680 for it. This is due to the new tab style as the previous, smooth build already had the new combined location bar.
(Assignee)

Updated

8 years ago
Depends on: 593690
(Assignee)

Updated

8 years ago
Blocks: 592265
(Reporter)

Comment 29

8 years ago
Created attachment 472635 [details]
Menubar -moz-appearance: none

(In reply to comment #19)
> (In reply to comment #18)
> > Just one more thing: the menubar is still not "flat". In Clearlooks, it "just"
> > draws a line between menu and toolbars which however looks bad especially with
> > tabs on top. Other themes even draw real boxes around the whole menubar. A
> > -moz-appearance: none on the menubar should solve the problem I think and bring
> > us another step closer to the mockup.
> 
> It would actually regress the menu bar appearance for various gtk themes (i.e.
> those that connect the menu bar with the title bar).

Yeah unfortunately that won't.

I think it would work in most cases if there were some way to get the background color of the menubar and apply it to the tabbar and the menubar.
Depends on: 593680

Comment 30

7 years ago
option please? maybe bout:config to go to the GTK theme so that uses with a good theme will have a consistent look?

So that we don't look like the **** apps that have their own non-conforming hteme that hurts the eyes in contrast?
(Assignee)

Updated

7 years ago
No longer depends on: 593680
You need to log in before you can comment on or make changes to this bug.