231313 - XUL tabs on Mac OS X render as 10.2-style tabs

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Steven Garrity [:sgarrity]]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040105 Firebird/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040105 Firebird/0.7+

The Page Info window, and any other place that uses OS X tabs, should use the
new OS X tabs that were introduced in OS X 10.3 (Panther).

Here's a screenshot of a window that uses the correct new tabs:
http://www.diveintoosx.org/images/2003/10/directory_access_main.jpg

This does NOT apply to the tab-browsing tabs - they aren't native and probably
won't be.

Reproducible: Always

Steps to Reproduce:
1. Right click in a page
2. Choose View Page Info

Actual Results:  
See old-style OS X tabs

Expected Results:  
You should see the new style Panther tabs

Comment 1

[Jonathan Louie]

confirmed Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b)
Gecko/20040308 Firefox/0.8.0+

Comment 2

[Asaf Romano (gone)]

*** Bug 243044 has been marked as a duplicate of this bug. ***

Comment 3

[Asaf Romano (gone)]

We can't implement it using the Appearance Manager.

Comment 4

[Ari]

I just tested it. Switching to HITheme doesn't help on Panther as of 10.3.7. It still draws the old tabs.

See http://lists.apple.com/archives/carbon-development/2003/Oct/msg01404.html

Comment 5

[Simon Fraser [no longer active]]

Native tabs are going away; they've already been replaced in trunk builds.

Comment 6

[Asaf Romano (gone)]

Simon, this is not a Camino bug, and we're not reffering to browser-tabs.

Comment 7

[Asaf Romano (gone)]

From http://lists.trolltech.com/qt4-preview-feedback/2004-12/thread00239-0.html :

"This is a long story. But basically it boils down to we use Appearance 
Manager to draw tabs (and  HIThemes on 10.3). Neither of these APIs 
provide anything for "Panther-Style" tabs. We will support them 
natively in 10.4 (where an API actually exists) and we will probably 
emulate before the next beta is out. Choosing to use the built-in style 
or write it yourself is a tough balance. Having the System draw your 
stuff offers much more insulation. However, when you can't get what 
people expect, you start looing out-dated.

So, yes, we are aware of it and it will get fixed."

Comment 8

[Asaf Romano (gone)]

*** Bug 294657 has been marked as a duplicate of this bug. ***

Comment 9

[Asaf Romano (gone)]

*** Bug 290484 has been marked as a duplicate of this bug. ***

Comment 10

[Jo Hermans]

*** Bug 295496 has been marked as a duplicate of this bug. ***

Comment 11

[Stefan [:stefanh]]

*** Bug 296164 has been marked as a duplicate of this bug. ***

Comment 12

[Asaf Romano (gone)]

*** Bug 305320 has been marked as a duplicate of this bug. ***

Comment 13

[Jo Hermans]

*** Bug 327915 has been marked as a duplicate of this bug. ***

Comment 14

[Håkan Waara]

From http://lists.apple.com/archives/carbon-development/2003/Oct/msg01404.html:

"There won't be any way to use DrawThemeTab to draw the new tabs. You will have to use HIThemeDrawTab. This shouldn't be too difficult; you'll just need to create a CG context from your QD port, and then substitute HIThemeDrawTab for DrawThemeTab."

He then goes on to say that event HIThemeDrawTab didn't draw the right tabs, but that was going to be fixed.   That message was almost 3 years ago though, so with a little luck, this approach could work now.

Does anyone know if this workaround is possible for us?

Comment 15

[Mark Mentovai]

Attachment: Some fiddling around

I was playing around with this for fun, just to see if it was possible.  This patch implements HITheme tabs that almost match the appearance introduced in 10.3 (Panther).  I say "almost" because the tab pane doesn't run through the tabs as in the native appearance.  This is because the rect that we get for the tab pane from Gecko doesn't overlap with the rects for the tabs, and in any event, the drawing order is wrong so the pane could draw over the tabs.

Comment 16

[Mark Mentovai]

Attachment: Appearance with the previous patch

Comment 17

[Uri Bernstein]

*** Bug 348409 has been marked as a duplicate of this bug. ***

Comment 19

[Pat]

Are there any plans on fixing this for Firefox 3.0? It really needs to be fixed to be more Mac like.

Comment 20

[Josh Aas]

It is unlikely that we'll fix this for Firefox 3. There are some complicated reasons that the new tab style doesn't mesh well with XUL layout right now, and while I agree it would be nice we have too many other things going on that are of a higher priority.

Comment 21

[Julien "_FrnchFrgg_" RIVAUD]

This bug has been fixed on linux by 265698, perhaps the ideas there can be helpful.

Comment 22

[Markus Stange [:mstange]]

Attachment: :-)

Comment 23

[Stefan [:stefanh]]

(In reply to comment #22)
> Created an attachment (id=326916) [details]
> :-)
> 

Excellent! And there will be a patch?

Comment 24

[Markus Stange [:mstange]]

Soon. I still need to figure out what to do about bottom / left / right tabs, different tab sizes, mousedown vs mouseclick, and ChatZilla...

Comment 25

[Stefan [:stefanh]]

(In reply to comment #24)
> Soon. I still need to figure out what to do about bottom / left / right tabs,
> different tab sizes, mousedown vs mouseclick, and ChatZilla...
> 

Maybe we shouldn't use native styling on bottom tabs?

Comment 26

[James Ross]

That would be better than the current Windows theme code, which draws them "upright" and makes it look so broken on bottom-tabs. :)

Comment 27

[Markus Stange [:mstange]]

I'm thinking about including some "predefined packages" into the CSS that allow you to customize the appearance of the tabs by choosing a combination of the following classes:
{ tabs-top, tabs-bottom } x { tabs-regular, tabs-small, tabs-mini } x
{ tabs-native, tabs-nonnative }
(where the first class is always the default styling).

So e.g. James might want to change chatzilla.xul#102 to
class="tabs-bottom tabs-small tabs-nonnative"

Does that sound reasonable?

For the non-native tabs I'd like to use the Adium style (see http://www.tbray.org/ongoing/When/200x/2005/12/16/-big/Adium-Chat-Window.png).

Comment 28

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: NSTabViews gone wild

Native tabs do support top/bottom/left/right tabs, though I've never seen a single one of the latter three in the wild ;)

The question is whether Gecko can be made to draw those other three correctly, and then, if so, if the usages in Gecko apps really align with NSTabViews or with some other concept of tab.

Comment 29

[Stefan [:stefanh]]

(In reply to comment #28)
> Created an attachment (id=326963) [details]
> NSTabViews gone wild
> 
> Native tabs do support top/bottom/left/right tabs, though I've never seen a
> single one of the latter three in the wild ;)

http://developer.apple.com/java/images/codeclips1.jpg ;-)

Comment 30

[Stefan [:stefanh]]

Actually, I can't be sure of that being bottom tabs from the screenshot.

Comment 31

[Markus Stange [:mstange]]

(In reply to comment #28)
Hehe, thanks Smokey, that looks cool.

> The question is whether Gecko can be made to draw those other three correctly,

Bottom tabs for sure, left / right tabs probably not until we support rotating text with CSS (bug 435293 ?).

> and then, if so, if the usages in Gecko apps really align with NSTabViews or
> with some other concept of tab.

Well, it looks like there are two different ways of using tabs in Gecko apps:
1) NSTabView-like usage: small and fixed number of tabs, plenty of space
2) ChatZilla-like usage: unknown and unlimited number of tabs, little space

The new tabs would only fit for style (1). I think the style packages that I proposed in comment 27 would solve the problem quite nicely.

Comment 32

[Stefan [:stefanh]]

(In reply to comment #27)
> I'm thinking about including some "predefined packages" into the CSS that allow
> you to customize the appearance of the tabs by choosing a combination of the
> following classes:
> { tabs-top, tabs-bottom } x { tabs-regular, tabs-small, tabs-mini } x
> { tabs-native, tabs-nonnative }
> (where the first class is always the default styling).
> 

(I think you mean tab-top, tab-bottom etc?)

The only potential problem I can think of atm is if you'll have a cross-platform xul file with different ui requirements. For example, native-styled regular tabs on mac, but small non-native tabs on win/nix. I'm not really sure if/when that would be the case, though.

Comment 33

[Markus Stange [:mstange]]

(In reply to comment #32)
> (I think you mean tab-top, tab-bottom etc?)

I thought that these classes could be set on the <tabbox> and on the <tabs> element, so I think tabs-* makes more sense. They shouldn't be set on individual tabs (<tab> elements).

> The only potential problem I can think of atm is if you'll have a
> cross-platform xul file with different ui requirements. For example,
> native-styled regular tabs on mac, but small non-native tabs on win/nix. I'm
> not really sure if/when that would be the case, though.

Yeah, that's a problem. You can't choose from these packages via CSS.

That's why I'd like a CSS syntax like this:

@template 'tabs-small' {
  ::elem {
    margin: 0 5px;
  }
  ::elem tab {
    -moz-appearance: tab;
  }
}

#myTabbox {
  apply-template: 'tabs-small';
}

which would be translated to:

#myTabbox {
  margin: 0 5px;
}
#myTabbox tab {
  -moz-appearance: tab;
}

... but that's not something we should discuss in this bug.

Comment 34

[Markus Stange [:mstange]]

Attachment: Screenshot of different tab styles

This is what I've got now. Still needs a bit of tweaking before I can submit useful patches.

Comment 35

[Markus Stange [:mstange]]

Attachment: part 1 v0.1: Rendering

Comment 36

[Markus Stange [:mstange]]

Comment on attachment 330836 [details] [diff] [review]
part 1 v0.1: Rendering

This patch is on top of that in bug 446463.

Comment 37

[Markus Stange [:mstange]]

Attachment: part 2 v0.1: Tab CSS Styles

I'm not sure about these class names yet, but I haven't got a better idea.

The height change in browser.css (height: 27px -> 25px) is necessary because 25px is what's actually intended - the additional 2px were a workaround for the |tabs|'s margin-bottom: -2px...

Comment 38

[Markus Stange [:mstange]]

Attachment: XUL playground for different tab styles

This is the basis of the screenshot in attachment 327246 [details]. There are awkward focus and partial redraw bugs when switching tabs, but they're not caused by my patches.

Comment 39

[Markus Stange [:mstange]]

Attachment: rendering part, v2

This patch is on top of that in bug 465402.

Comment 40

[Markus Stange [:mstange]]

Attachment: css part, v2

I removed all the class-customization stuff from the previous patch. Now the only class that's supported is "tabs-bottom", which will switch to small, left-aligned, Adium-style tabs.

The custom tabpanels padding in the preferences window prevents the "Always check to see if Minefield is the default browser on startup" checkbox label from wrapping. The dynamic preferences window sizing doesn't interact well with wrapping labels... (see bug 345572 and bug 349098).

Comment 41

[Markus Stange [:mstange]]

Attachment: rendering part, v2.1

The previous patch resulted in invisible tabpanels on 10.4. We also need to set tpdi.kind = kHIThemeTabKindNormal.

Comment 42

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 349201 [details] [diff] [review]
rendering part, v2.1

+  void DrawTab(CGContextRef context, HIRect inBoxRect, PRInt32 inState,

const HIRect& inBoxRect?

Comment 43

[Dão Gottwald [:dao]]

Comment on attachment 349200 [details] [diff] [review]
css part, v2

Any reason against using :first-child / :last-child instead of [first-tab=true] / [last-tab=true]?

Comment 44

[Dão Gottwald [:dao]]

Comment on attachment 349200 [details] [diff] [review]
css part, v2

>+tabbox.tabs-bottom > tabs, tabs.tabs-bottom {

line-break after comma, please.

Comment 45

[Markus Stange [:mstange]]

Attachment: css part, v3

(In reply to comment #43)
> (From update of attachment 349200 [details] [diff] [review])
> Any reason against using :first-child / :last-child instead of [first-tab=true]
> / [last-tab=true]?

I don't see any reason against it :)
I probably did it because winstripe's tabbox.css also uses these attributes, but I don't really remember.

(In reply to comment #44)
> line-break after comma, please.

Done.

Comment 46

[Dão Gottwald [:dao]]

Comment on attachment 349498 [details] [diff] [review]
css part, v3

> .tabs-left, .tabs-right {

please insert a line break as well

> .tabs-left, .tabs-right {
>+  -moz-box-flex: 1 !important;

>+tabbox.tabs-bottom > tabs,
>+tabs.tabs-bottom {
>+  padding: 0 !important;
>+  margin: 0 !important;

>+tabs.tabs-bottom > .tabs-left {
>+  -moz-box-flex: 0 !important;

>+tabbox.tabs-bottom > tabs > tab[beforeselected=true],
>+tabs.tabs-bottom > tab[beforeselected=true] {
>+  -moz-border-end-color: transparent !important;

all these !important flags seem unnecessary

Comment 47

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

Comment on attachment 349498 [details] [diff] [review]
css part, v3

a191=beltzner with dao's nits addressed

Comment 48

[Shawn Wilsher :sdwilsh]

http://hg.mozilla.org/mozilla-central/rev/ae7706acc2d2

Comment 49

[Shawn Wilsher :sdwilsh]

also http://hg.mozilla.org/mozilla-central/rev/7463787cec76