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

RESOLVED INCOMPLETE

Status

()

Firefox
Shell Integration
RESOLVED INCOMPLETE
11 years ago
8 years ago

People

(Reporter: Jakub 'Livio' Rusinek, Unassigned)

Tracking

(Depends on: 1 bug)

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [CLOSEME 2010-09-15])

Attachments

(6 attachments)

(Reporter)

Description

11 years ago
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
(Reporter)

Comment 1

11 years ago
Created attachment 297071 [details]
screenshot
(Reporter)

Comment 2

11 years ago
Created attachment 297073 [details]
example of native gtk tabs
Version: unspecified → Trunk

Comment 3

11 years ago
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
(Reporter)

Updated

11 years ago
Component: Widget: Gtk → OS Integration
Product: Core → Firefox
Summary: wrong bg color inside notebook widget in main window → use native notebook widget to display tab panels in tab browser

Comment 4

11 years ago
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;
}
(Reporter)

Comment 5

11 years ago
Sometimes current tab is drawn in a strange way.
I have xmag'ed part of a tab.
(Reporter)

Comment 6

11 years ago
Created attachment 297194 [details]
problem when using userchrome.css
QA Contact: gtk → os.integration
(Reporter)

Comment 7

11 years ago
ping
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.
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
(Reporter)

Comment 10

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

Comment 11

11 years ago
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!
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 ?
(Reporter)

Comment 13

11 years ago
Created attachment 298463 [details]
wrong bg
(Reporter)

Comment 14

11 years ago
Created attachment 298500 [details]
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.
(Reporter)

Comment 15

11 years ago
previous screenshot (attachment #298463 [details]) has shown white-bg vs. current tab's bg "color conflict".
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)
(Reporter)

Comment 17

11 years ago
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.
(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.
(Reporter)

Comment 19

11 years ago
https://bugzilla.mozilla.org/attachment.cgi?id=297071
Don't you see color difference in there?
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 ?
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 407775
(Reporter)

Comment 22

11 years ago
The lower one is WRONG! I'm repeating and repeating and you still do not understand... OMG!
"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.
(Reporter)

Comment 24

11 years ago
it's not really duplacate of bug #407775.
407775 is about borders/etc, mine is about notebook background and some embedded pages background color.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
(Reporter)

Comment 25

11 years ago
Created attachment 300371 [details]
color difference between 1 and 2
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.
Changing summary to address the only remaining issue, and depending on 407775 in which what to do with borders will be decided.
Depends on: 407775
Summary: use native notebook widget to display tab panels in tab browser → [gtk] XUL error pages (and the like) should use a background matching notebook widget when tabstrip is visible
(Reporter)

Comment 28

11 years ago
Bug addresses to the about:config too, since first element on that page is XUL object.
That's the goal of "and the like"
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
Whiteboard: [CLOSEME 2010-09-15]
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.