412359 - [gtk] XUL error pages (and the like) should use a background matching notebook widget when tabstrip is visible

Status: RESOLVED INCOMPLETE

(Firefox :: Shell Integration, defect)

Description

[u294409]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9b3pre) Gecko/2008011404 openSUSE/10.3 Minefield/3.0b3pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9b3pre) Gecko/2008011404 openSUSE/10.3 Minefield/3.0b3pre

firefox draws wrong color in main window's notebook widget.

Reproducible: Always

Actual Results:  
wrong color inside notebook

Expected Results:  
everything ok

Comment 1

[u294409]

Attachment: screenshot

Comment 2

[u294409]

Attachment: example of native gtk tabs

Comment 3

[Teune van Steeg]

The tab panels in the browser are (probably on purpose) not drawn as notebook. This bug should either be marked INVALID or renamed to something like "use native notebook widget to display tab panels in tab browser" under Firefox: OS integration

Comment 4

[Ian Spence]

Jakub, trying adding the following to your userChrome.css file and tell me if it is what you are looking for.

/* CSS to make tabbrowser look more... notebook-like */
#appcontent tabpanels {
	-moz-appearance: tabpanels !important;
}

#appcontent browser {
	border: 1px solid threedshadow !important;
}

.tabs-bottom {
	border: none !important;
}

.tabbrowser-tab {
	margin-bottom: 0 !important;
}

Comment 5

[u294409]

Sometimes current tab is drawn in a strange way.
I have xmag'ed part of a tab.

Comment 6

[u294409]

Attachment: problem when using userchrome.css

Comment 7

[u294409]

ping

Comment 8

[Julien "_FrnchFrgg_" RIVAUD]

The solution of Ian make us hit bug 408059 which prevents the tab to draw reliably outside of his bounds (to erase the tabpanels top border).

To avoid it, a -2px margin could be set on active tab, but then it should be put higher (in z-index) than the tabpanels. I tried to set z-indexes, but didn't succeed. I think there are difficulties coming from the use of stacks.

Comment 9

[Julien "_FrnchFrgg_" RIVAUD]

Note that for a better look we could keep only the top border of #appcontent tabpanels and #appcontent browser, hiding others since they aren't that useful

Comment 10

[u294409]

Hey, I wanted to change color INSIDE notebook to a native one.
I've shown color difference in screenshot.
Haven't you seen it?

Comment 11

[u294409]

And about native tabs...

This white field isn't part of notebook, but TextView widget (etc).
The border you wanted me to add to userChrome isn't needed!

Comment 12

[Julien "_FrnchFrgg_" RIVAUD]

Jakub: I don't understand what you want, sorry. I think our current rendering of tab background color is exactly as on native gtk apps; the only part that isn't drawn currently for the browser tabs is the top part of the notebook, which you say this bug isn't about.
So what are you asking ? Perhaps you could make a more detailed explanation ?

Comment 13

[u294409]

Attachment: wrong bg

Comment 14

[u294409]

Attachment: description, what's wrong

1 is color, which fills notebook, same as in current tab's bottom part

2 is window bg color

3 is widget inside notebook, filled with appropriate color

--

firefox instead of color 1 fill notebook area using color 2 (what is wrong), but it would only fix it, and add border inside notebook, to emulate widget inside notebook - it would make white (or other specified in GNOME settings) color inside appropriate and argumented.

for now using white color without any borders look strange - color difference in eg. clearlooks theme is noticeable - tab ends and white area begins. it looks very strange.

Comment 15

[u294409]

previous screenshot (attachment #298463 [details]) has shown white-bg vs. current tab's bg "color conflict".

Comment 16

[Julien "_FrnchFrgg_" RIVAUD]

I don't understand why you say that Firefox wrongly uses the color "2" instead of color "1". I only see color "1" (and white) and this is what I expect by reading the source code.

So you mean that Firefox should use the tab background color for the background of HTML pages, or use a border to make this white logical (the solution proposed in the userChrome.css) ? Any solution should take into account that pages can specify black backgrounds, or on the contrary expect white backgrounds by default (so using the default GTK widget background probably isn't an option, especially considering dark themes)

Comment 17

[u294409]

Firefox doesn't draw notebook native way.

> use a border to make this white logical (the solution
proposed in the userChrome.css)

That's better, because white, or other background specified by website there looks like bg of another widget inside.

But border around white area sometimes causes strange glitches with drawing current tab...
Test is yourself.

Comment 18

[Julien "_FrnchFrgg_" RIVAUD]

(In reply to comment #17)
> Firefox doesn't draw notebook native way.

Yes, it does (or should) since my work on bug 265698.

Any problem you still see may be a bug, but you need more that "doesn't draw native" for the bug to be considered. We *try* to draw it native, and if you don't explain *what* we do wrong, we cannot fix it, since we don't see it. Your eyes are very valuable since you detect a lot of things, but it's often difficult to understand what you want to tell us. I understand that your first language isn't english, and neither is mine, so it's sometimes difficult...

Note that I already acknowledged the issue with the HTML background next to the tab background without transition, but I had the impression that there was another problem you wanted us to fix.
If the only problem is the previous one, say something like "the current page should be visually in a widget in the tab, see attachment 297073 [details]" in the bug summary.

If there are other problems, explain them carefully, and we'll see if it is the same bug or if other bugs should be filed.

Comment 19

[u294409]

https://bugzilla.mozilla.org/attachment.cgi?id=297071
Don't you see color difference in there?

Comment 20

[Julien "_FrnchFrgg_" RIVAUD]

I don't understand what attachment 297071 [details] means. Which color is wrong, the upper one or the lower one ? And the part where contrast is turned up just seems darker here. I can see a little difference, but it is really small.

Trying to understand, I suppose that what you mean is that the background color is darker than the tab bg for XUL pages and when the page is still loading in a new tab ? That is we use the dialog background color ?

I really think this part of the bug is to be ignored, since the bg color in the content can be anything, and dialog bg is correct for XUL pages (and when the page is still loading). In any case, if we make a visual distinction between the tab and the inner content by adding a border, then the difference in color won't matter anymore.

What do you think ?

Comment 22

[u294409]

The lower one is WRONG! I'm repeating and repeating and you still do not understand... OMG!

Comment 23

[Julien "_FrnchFrgg_" RIVAUD]

"I suppose that what you mean is that the background color
is darker than the tab bg for XUL pages and when the page is still loading in a
new tab ? That is we use the dialog background color ?" means that the lower color is wrong since it is the dialog background instead of tab background

We cannot do much about it, since XUL pages should have that background by default, and anyway for any page when the page is finished loading we cannot control anymore the color.

Note that my patch on bug 407775 makes (as a side effect) the background be the one you want while the page is still loading (for a new tab), so you'll get what you want. It's no use repeating if I don't understand what you want to say, it's far better to try and rephrase.

If there are still issues here not taken care of in bug 407775, file a new bug for each precise issue.

Comment 24

[u294409]

it's not really duplacate of bug #407775.
407775 is about borders/etc, mine is about notebook background and some embedded pages background color.

Comment 25

[u294409]

Attachment: color difference between 1 and 2

Comment 26

[Julien "_FrnchFrgg_" RIVAUD]

Jakub: The problem is that the XUL error page probably has no means to know whether it is into a tab or not, and its background cannot be transparent. So it is drawn with the default XUL background which is the dialog bg. I'm not really convinced it's wrong, but either case what we choose for bug 407775 will change what is the solution here.

If there is no inner widget in the tab, then arguably the right color is the tab background color when in a tab, and the dialog color when the tabstrip is hidden.

But if there is an inner widget (that is the first up rendering in first mockup of bug 407775), then the logical color would be the background of a scrollbox, but since there would be a border any color would do.

Comment 27

[Julien "_FrnchFrgg_" RIVAUD]

Changing summary to address the only remaining issue, and depending on 407775 in which what to do with borders will be decided.

Comment 28

[u294409]

Bug addresses to the about:config too, since first element on that page is XUL object.

Comment 29

[Julien "_FrnchFrgg_" RIVAUD]

That's the goal of "and the like"

Comment 30

[Tyler Downer [He/Him]]

Reporter, are you still seeing this issue with Firefox 3.6.8 or later in safe mode? If not, please close. These links can help you in your testing.
http://support.mozilla.com/kb/Safe+Mode
http://support.mozilla.com/kb/Managing+profiles

Comment 31

[Tyler Downer [He/Him]]

No reply, INCOMPLETE. Please retest with Firefox 3.6.10 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.