Gnomestripe: make the tab strip look native

VERIFIED FIXED in Firefox 3 beta2

Status

()

Firefox
Tabbed Browser
--
enhancement
VERIFIED FIXED
11 years ago
8 years ago

People

(Reporter: dao, Assigned: rflint)

Tracking

(Blocks: 1 bug)

Trunk
Firefox 3 beta2
All
Linux
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3 -
wanted-firefox3 +
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060922 Minefield/3.0a1
Build Identifier: 

I think Gnomestripe should use native-looking tabs. Contrary to Windows, I have yet to see a screenshot where the new tabs look and fit better.

Reproducible: Always
(Reporter)

Updated

11 years ago
Blocks: 353673
(Reporter)

Updated

11 years ago
Blocks: 347454
No longer blocks: 353673
(Reporter)

Updated

11 years ago
Summary: Gnomestripe: make the tabs look native → Gnomestripe: make the tab strip look native
Hardware: PC → All
Blocks: 233462
Created attachment 239915 [details]
Some screenshots

...including GTK accessibility themes.
As you can see in the attached screenshot, the desired goal to make the active tab more distinct than the inactive is not achieved in most of the themes - the  native look is better and more distinct.

Also this new tab bar looks really silly with minimalistic themes.
*** Bug 354960 has been marked as a duplicate of this bug. ***
Until this is fixed, a local workaround, for all of you suffering from this bug, is to replace skin/classic/global/browser.css in chrome/classic.jar with this version:

http://beta.aviary.pl/marcoos/theme/browser.css

(I took it from the QuBranch theme).
(Reporter)

Updated

11 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WONTFIX
(Reporter)

Updated

11 years ago
Version: unspecified → 2.0 Branch
Why is this marked WONTFIX? Without a reason for that, this bug is still (very) valid.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
still valid for trunk
Version: 2.0 Branch → Trunk
(Reporter)

Comment 7

11 years ago
(In reply to comment #5)
> Why is this marked WONTFIX? Without a reason for that, this bug is still (very)
> valid.

"Won't fix" doesn't mean it's invalid.
It was just my guess, because Firefox 2 is released and going back seems unlikely. Plus, the response to this bug wasn't too overwhelming.
Severity: normal → enhancement

Comment 8

11 years ago
Why do you think, you should work around a "limitation" of Gnome/windows themes to make the active tab button more prominent? Rather create a "better" gnome/windows theme than making firefox less native again :(

It may look ok in default gnome/windows installs, but on minimalistic/flat gtk+ themes, it just stand out sooo much. At least some (easy) userChrome.css option for this would be nice.
(In reply to comment #8)
> At least some (easy) userChrome.css option
> for this would be nice.

See comment 4.

Comment 10

11 years ago
(In reply to comment #9)
> (In reply to comment #8)
> > At least some (easy) userChrome.css option
> > for this would be nice.
> 
> See comment 4.

Oh I am so sorry, I even tried that before but was stupid to exchange /skin/classic/browser/browser.css instead of
/skin/classic/global/browser.css

Still no perfect solution, as one has to repeat this thing every time you upgrade Firefox, but at least it looks perfect now, thanks a lot!

Comment 11

10 years ago
AFAIK these self-painted tab bars were only introduced, to work around the not-so-high-contrast native design of Windows. This is not needes on Linux as there is no "default" Design. Our tabbar looks out of place in many gtk-themes, too.
Flags: blocking-firefox3?
We're going to do this, partly for perf reasons, but also because unlike Windows, "native" tabs are actually used in other browsers.  Not a blocker though.
Assignee: nobody → rflint
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-firefox3? → blocking-firefox3-
Whiteboard: [wanted-firefox3]
Depends on: 399937
Duplicate of this bug: 399801
Status: NEW → ASSIGNED

Comment 14

10 years ago
Created attachment 285065 [details] [diff] [review]
Patch

This patch seems to do it. It will actually end up making the tabbar more native than Fx1.5, because this patch will use the stock close icon on the close buttons, as Epiphany uses.
Assignee: rflint → ventnor.bugzilla
Attachment #285065 - Flags: review?(mconnor)
Considering that I've already done this and that hacking up winstripe is wrong direction to be headed in, I'm going to go ahead and take this back, but thanks anyway.
Assignee: ventnor.bugzilla → rflint
Status: ASSIGNED → NEW
Attachment #285065 - Attachment is obsolete: true
Attachment #285065 - Flags: review?(mconnor)

Comment 16

10 years ago
OK, sorry.
But for bug 399937 to be fixed, to end winstripe hacking, wouldn't we need to wait for the new icon set to be made, or will we just copy over Winstripe's images?

Comment 17

10 years ago
Oh, and did you use the stock close icon in your patch? That would greatly increase the native feel of the tabbar, pushing us beyond Fx 1.5.
I've got a few patches I'd like to get into winstripe to cut it down a bit before requesting the CVS copies (should have that done before the end of the week). If the new icon set's already in by then or reviewed/ready, I'll just change or exclude it from the copy and get it taken care of before we make gnomestripe part of the build.

I used the stock icon on the tabs, but kept the current winstripe version for the tab strip button because it looked a little out of place there - I'll try it again once I've got the changes to the tab strip/tab backgrounds in.

Comment 19

10 years ago
I'm sorry but what about Qt/KDE? Linux is not just a Gnome. And as a developer myself I can tell you that Qt4 is far more superior than the gtk+. So having so many noice about Gnome/Gtk+ are you planning to implement this for qt also?

Thanks.

Comment 20

10 years ago
Firefox is a GTK application on Linux, and always has been. Mike Connor said on his blog that the reason we don't support Qt is because there are no volunteers willing to implement all of the Mozilla platform in Qt. And there is no need to start another Qt vs GTK war.
(In reply to comment #19)
> I'm sorry but what about Qt/KDE? Linux is not just a Gnome. And as a developer
> myself I can tell you that Qt4 is far more superior than the gtk+. So having so
> many noice about Gnome/Gtk+ are you planning to implement this for qt also?

Quoting from http://steelgryphon.com/blog/?p=108, "Qt doesn’t get much love, but we’ve asked/begged/pleaded for interest, and no one really seems to have it, including the distros that invest time into Firefox". So, if you're willing and offering to help, jump right in! :)

Comment 22

10 years ago
I thought that Mozilla is a organization which is focused on the developing of Firefox browser. It receives donations from different organizations. And according to some articles I've read (for example http://slashdot.org/article.pl?sid=07/05/21/156213) it has a solid revenue. Looking at these numbers (from the article above) I am sure that this revenue many times exceeds the revenue of software company I work in. I am telling this because I was sure that you (Mozilla Foundation) have full time dedicated developers that work on Firefox.

Unfortunately I currently can't participate in a open source project like Firefox due to some personal reasons.

Firefox is an open source project and this allows every interested person to participate in. And volunteering is important for the open source project. But I thought you have full time dedicated developers that work only on Firefox. That is why I had no idea that volunteering is so important for Firefox. 

In my imagination Mozilla Foundation is a large organization with a lot of dedicated full time payed developers which produce a product. I understand that volunteering is critical for a small open source project without payed developers. But frankly speaking I thought that due to a serious support and donations from different organizations Firefox is in absolutely different situation. If I am wrong about this I can understand this.

But I say it again, I always thought of Mozilla Foundation as about organization  which has enough support to be able to produce a product without volunteering help. And looking at some of your documentation like
http://developer.mozilla.org/en/docs/Configuring_Build_Options 
I thought that you are working on Qt support (Graphics Toolkit section of above page).

I do not want to start any "war" or even argument. But from you words it seems that Firefox can't be developed without volunteering help. I was absolutely positive that it is not true. But from your words it seems that I was wrong.
Blocks: 401931

Comment 23

10 years ago
Ryan, I'm using Gnomestripe now due to my own Makefile. You checked in the native tabbar earlier and it works very well. One caveat is that the tab throbber no longer works. Its due to this:

.tabbrowser-tab[busy] > .tab-icon-image {                                       
  list-style-image: url("chrome://global/skin/throbber/Throbber-small.gif") !imp
ortant;
  opacity: 0.6;
}

which should be:

.tabbrowser-tab[busy] .tab-icon-image {

since tab-icon-image is not a _direct_ child of the tab. Same goes for the -moz-grab rule below that.
(In reply to comment #23)
It's going to be a direct child soon, you'll need to apply this patch in the interim: http://pastebin.mozilla.org/241948
Fixed by turning on Gnomestipe.
The issues noted in comment 23 will go away once bug 387345 lands.
Status: NEW → RESOLVED
Last Resolved: 11 years ago10 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3 M10

Comment 26

10 years ago
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007112619 Minefield/3.0b2pre ID:2007112619


(In reply to comment #23)
> One caveat is that the tab throbber no longer works.

Tab throbber (rotating image shown while a tab is loading) WFM.

Comment 27

10 years ago
v. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007112704 Minefield/3.0b2pre ID:2007112704
Status: RESOLVED → VERIFIED
Depends on: 409523

Comment 28

10 years ago
This bug is still valid for the preferences dialog as well as the add-ons dialog. I think it should be reopened.

Comment 29

10 years ago
Created attachment 295070 [details]
Example how the add-ons dialog is supposed to render in a GTK environment
(In reply to comment #28)
> This bug is still valid for the preferences dialog as well as the add-ons
> dialog. I think it should be reopened.

File another bug.
Flags: wanted-firefox3+
Whiteboard: [wanted-firefox3]
You need to log in before you can comment on or make changes to this bug.