174629 - GTK native theme tab widget doesn't look quite right

Status: RESOLVED DUPLICATE of bug 265698

(Core :: XUL, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The GTK native theme tab widget doesn't look quite right because it's missing
the bottom borders on the tabs.  All tabs except for the active tab should have
a black bottom border at the bottom, and a white border below that for 3D effect.

I'll attach a screenshot that has windows in the arrangement:

,-------------v-------------.
| Non-native  | GTK-native  |
| Mozilla     | Mozilla     |
|      ,---------. (Xft too)|
|      | GTK App |          |

I'll then attach two variants of this screenshot with the Native theme GTK
Mozilla edited -- the first edited version has only the black line added (which
would be acceptable behavior, I think) and the second edited version has both
the black and white lines added (which is preferable, although the editing may
scrunch the vertical size more than it ought to).

There's a possibility that this could just be a sizing issue because other
things are painting over the bottom part of the tabwidget.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: real screenshot

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: screenshot edited to show black line below non-active tabs

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: screenshot edited to show both lines below non-active tabs

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I should have been clearer in my description of expected behavior -- that's the
expected behavior using my theme (which is the RH8 Bluecurve theme), but the
expected behavior is probably different for other themes.  I would expect that
other themes have similar problems, although I haven't tested.  I did hear some
negative comments on IRC about the appearance of the tabs with the GTK native
theme code enabled, but I don't know if the people who made those comments were
using a different theme.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I was investigating this a little.  It looks like GTK draws that border as part
of gtk_notebook_paint.  I think there are two problems with our code:  first,
that moz_gtk_tabpanels_paint is equivalent to gtk_notebook_paint for the case
where the notebook has no tabs and leaves no room for them, and second, because
moz_gtk_tabpanels_paint is never called.  There would probably be a third
problem that we don't know exactly how much room we're supposed to leave when
painting the tabpanels, as opposed to the tabs, because GTK's model of tabs
within notebook is different from ours with tabs outside of tabpanels.

Don't trust me on this, though.  I'm probably not very good at understanding GTK
code that I've never seen before on under three hours of sleep.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Ignore my comments about the problem with the different models.  GTK's model
requires knowing the tab size when painting the notebook, but our model doesn't,
and that's good.

However, I think we do:
 * need to make sure moz_gtk_tabpanels_paint is called
 * maybe need to do a little border-offsetting to get the box in the right place
 * use gtk_paint_box_gap rather than gtk_paint_box (which is what
gtk_notebook_paint uses when there are no tabs), and figure out the right gap
(which seems like it might be just as hard as the problem I was worrying about
in my previous comment)

Comment 7

[Brian Ryner (not reading)]

One possibility would be to paint the top of the tabpanels box as part of the
tabs, i.e. at the bottom of the tab.  I think hyatt might have some ideas on
this, as he mentioned that this doesn't work quite right on WinXP either.

Comment 8

[Julien "_FrnchFrgg_" RIVAUD]

This is strongly tied to bug 265698, which has had for a long time a candidate patch, which never got any review, because potential reviewers utterly lack time...
Strangely I didn't notice this bug when I worked on 265698...

Comment 9

[Julien "_FrnchFrgg_" RIVAUD]

We should mark bug 265698 as a dupe of this one, or the other way around. The latter may be better since all the work is being done in bug 265698.