Open Bug 236107 Opened 21 years ago Updated 2 years ago

wrong background for groupbox caption when used in tab panels

Categories

(Toolkit :: UI Widgets, defect)

x86
All
defect

Tracking

()

REOPENED
Future

People

(Reporter: p_ch, Unassigned)

References

Details

(Keywords: fixed1.8, fixed1.9.1, polish, Whiteboard: [polish-hard] [polish-visual][polish-p2])

Attachments

(7 files, 1 obsolete file)

The captions in groupbox shouldn't set their own background color. The problem appear clearly when the dialog/window background is a pixmap.
fixed.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Reopening, the groupbox border is now apparent through the caption...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Bug 236338 has been marked as a duplicate of this bug. ***
Keywords: regression
I see this on Windows XP too (currently marked as a Linux bug).
mhmm, the solution won't likely be cross platform.
I'm seeing the bug where the border is through the captions in the options (and download dialog) of build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040302 Firefox/0.8.0+ . Have you already backed the change causing this out? If so then please ignore my previous comment - I'm not sure if the original bug appears on Windows.
Keywords: regression
*** Bug 236691 has been marked as a duplicate of this bug. ***
*** Bug 236814 has been marked as a duplicate of this bug. ***
--> OS to All This is being seen on Windows too.
OS: Linux → All
*** Bug 236929 has been marked as a duplicate of this bug. ***
OK, the bug I was seeing has been fixed in the latest nightlies on WinXP (I think pch backed out his original fix that caused the bug I saw). Does the original bug apply to windows too or should this bug be changed back to linux only? I don't see any problems with the groupboxes on Win XP any more.
Attached image Image showing the bug
I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040729 Firefox/0.9.1+. This bug is still there on Windowx XP. Have a look to the attached image (Options Dialog in easyGestures extension).
Bug is still present in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040806 Firefox/0.9.1+ Using Windows XP.
This bug is still very much alive, and is pretty obvious in Windows XP w/ Luna in the Options dialog in the latest nightly FFs.
(In reply to comment #15) > This bug is still very much alive, and is pretty obvious in Windows XP w/ Luna > in the Options dialog in the latest nightly FFs. On Windows Classic, it's worse, since the window's gray differs severely from the inner frame's white. (Firefox 1.0)
Flags: blocking-aviary1.1?
Kevin, we set a background on caption here, we don't need this, we should just be transparent I think, unless you feel like getting el neato somehow. http://lxr.mozilla.org/mozilla/source/toolkit/themes/winstripe/global/groupbox.css#60
Assignee: p_ch → kevin
Status: REOPENED → NEW
Flags: blocking-aviary1.1? → blocking1.8b4+
Making the caption background transparent would make the groupbox border show through the middle of it. We don't have a background color to inherit in the case of the tab panel which is drawn by -moz-appearance. I'd like to get el neato, but I don't see how.
This seems logical: - If the background of the groupbox and the underlying pane are the same, get rid of the border somehow. If it's a solid color, it should be trivial. If it's a pixmap, I guess there would be hacking involved. - If the backgrounds differ, make the background of the groupbox extend into the label but not into the border. Just my 2 cents.
Whiteboard: [being worked on, eta?]
The drawing of groupboxes should be handled like a fieldset in HTML. There we have the same situation and the border is cropped under the label. Meanwhile adding "-moz-appearance: window;" to caption should do the trick. It will fetch solid backgrounds as well as pixelmaps and hides the underlaying border. Looks good for me under Linux. I could create a patch for every theme if you agree to use this way for now.
I forgot to mention that the same appears for Thunderbird. => Toolkit
Component: General → XUL Widgets
Product: Firefox → Toolkit
Attached image Screenshot with -moz-appearance:window (obsolete) —
Using -moz-appearance:window isn't quiet a good solution like it's visible here.
Attached patch Patch rev. 1Splinter Review
This fixes it for Firefox and SeaMonkey on Windows.
Attachment #192161 - Flags: first-review?(mconnor)
Attachment #192161 - Flags: first-review?(mconnor) → first-review?(kevin)
Comment on attachment 192161 [details] [diff] [review] Patch rev. 1 The toolkit changes look very good. The caption color doesn't precisely match the tab panel background using Luna, but it's darn close. Tested using Luna and Classic themes. Thanks for the patch! Can someone please quickly test this on Linux to make sure there isn't anything funky there?
Attachment #192161 - Flags: first-review?(kevin) → first-review+
Severity: normal → major
Attachment #192161 - Flags: second-review?(neil.parkwaycc.co.uk)
Comment on attachment 192161 [details] [diff] [review] Patch rev. 1 Sorry, I can't test this.
Attachment #192161 - Flags: second-review?(neil.parkwaycc.co.uk)
Comment on attachment 192161 [details] [diff] [review] Patch rev. 1 Can we have approval for the toolkit CSS changes only?
Attachment #192161 - Flags: approval1.8b4?
Attachment #192161 - Flags: approval1.8b4? → approval1.8b4+
Checked in toolkit changes on branch and trunk. Thanks Mats! global/groupbox.css Checking in toolkit/themes/qute/global/groupbox.css; /cvsroot/mozilla/toolkit/themes/qute/global/groupbox.css,v <-- groupbox.css new revision: 1.4; previous revision: 1.3 done Checking in toolkit/themes/winstripe/global/groupbox.css; /cvsroot/mozilla/toolkit/themes/winstripe/global/groupbox.css,v <-- groupbox.css new revision: 1.4; previous revision: 1.3 done
Status: NEW → RESOLVED
Closed: 21 years ago19 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8beta4
Sorry, but IMHO "Darn close" is not good enough. You can not solve this bug by applying a solid background color because the windows tab uses some kind of gradient color as a background of the tab, which means that a solid color might be darn good in one location in the tab, while being not so good at other locations.
Why do "tabpanels caption" belong to any groupbox children? That's a completely different part. When I remove the CSS rule from patch rev. 1 I can't see any difference with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050829 Firefox/1.0+. This bug is definetely NOT fixed! See my comment 22 for a working solution. It's not final but it should also work on any theme with a pixelmap until we have a final solution (perhaps from comment 20) here.
Status: RESOLVED → REOPENED
Keywords: fixed1.8
Resolution: FIXED → ---
Henrik, can you please post screenshots of what you see before and after applying the above patch?
(In reply to comment #30) > Henrik, can you please post screenshots of what you see before and after > applying the above patch? Like I already told there is no difference between this two stages. I always see a solid background. Screenshots follow.
Same style with and without patch rev. 1.
Keywords: fixed1.8
Asa, this bug is not fixed for the 1.8 branch! The checked-in patch doesn't chance anything for my Linux build. See the attached screenshots.
(In reply to comment #34) > Asa, this bug is not fixed for the 1.8 branch! The checked-in patch doesn't > change anything for my Linux build. See the attached screenshots. Henrik, The checked-in patch may not work for your specific OS theme, but your patch using -moz-appearance: window would not work for Luna, where tabpanels have a lighter appearance than the window. I don't think there is a CSS solution that will work for all OS themes. A true solution to this bug would be to have the OS draw the groupbox and we could just use -moz-appearance: groupbox. Since that is unlikely to happen for 1.5, I think the best we can do for now is make a CSS tweak that looks reasonable on the default OS themes where Winstripe runs (Luna, Windows Classic). Reassigning to the default owner..
Assignee: kevin → nobody
Status: REOPENED → NEW
QA Contact: xul.widgets
doesn't fix GTK, but moz-appearance: tabpanel should work ok on Windows, but "close enough" is all we're going to get for 1.5, but this seems right on Classic and Luna Blue, its a little off on Luna Silver though, but that's a lesser case.
Blocks: 304083
No longer blocks: 304083
(In reply to comment #36) > doesn't fix GTK, but moz-appearance: tabpanel should work ok on Windows, but > "close enough" is all we're going to get for 1.5, but this seems right on > Classic and Luna Blue, its a little off on Luna Silver though, but that's a > lesser case. Not for me with current beta1 and Windows XP Luna blue. The captions for groupboxes on tabpanels have a lighter background as the tabpanels.
*** Bug 307661 has been marked as a duplicate of this bug. ***
*** Bug 249705 has been marked as a duplicate of this bug. ***
Just so you know, it still happens on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051013 Firefox/1.4.1
Isn't bug 209228 a duplicate ?
*** Bug 318599 has been marked as a duplicate of this bug. ***
*** Bug 321507 has been marked as a duplicate of this bug. ***
(In reply to comment #41) > Isn't bug 209228 a duplicate ? > looks like Yes
*** Bug 209228 has been marked as a duplicate of this bug. ***
Still unresolved in FF 2.0.0.1; Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
I am seeing this using in Vista with Alpha 7 Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a7pre) Gecko/2007071213 Minefield/3.0a7pre
Keywords: polish
It's the same pb on every platform, namely that we don't know where the label is (and what width it has) when we draw the groupbox border, so we cannot make the label transparent. I'm afraid this would be very difficult to solve in the general case (if the background isn't a solid color, for instance, since we don't know where the frame is on that background when we paint it), unless we make the groupbox drawing aware of the width and pos of the label... which could be difficult. Clearing obsolete flags and keywords, lowering severity, and setting to future.
Severity: major → minor
Flags: blocking1.8b5+
Keywords: fixed1.8
Whiteboard: [being worked on, eta?]
Target Milestone: mozilla1.8beta4 → Future
If 'background-color' can't be set to 'transparent', is there a problem wth setting it to 'inherit'? It works on Windows (fx3b3)... I'm sorry if this is a stupid suggestion.
Depends on: 433566
This fixes it for me when using Aero and it looks the same with or without the patch on Classic. I believe this should also fix the slight color difference between the caption background and the tabpanel background on Luna. This does not fix Linux and Linux has its own css for this http://mxr.mozilla.org/mozilla-central/source/toolkit/themes/gnomestripe/global/groupbox.css
Assignee: nobody → robert.bugzilla
Attachment #364222 - Flags: review?(mconnor)
Attachment #364222 - Flags: review?(mconnor) → review+
Comment on attachment 364222 [details] [diff] [review] Windows fix (checked in) Windows only fix pushed to mozilla-central http://hg.mozilla.org/mozilla-central/rev/d10b74e2d200
Attachment #364222 - Attachment description: Windows fix → Windows fix (checked in)
Whiteboard: [polish-hard] [polish-visual]
Comment on attachment 364222 [details] [diff] [review] Windows fix (checked in) a191=beltzner
Attachment #364222 - Flags: approval1.9.1? → approval1.9.1+
Pushed to mozilla-1.9.1 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/6fc4052c759f I'm closing this bug. If there are additional issues please file a new bug. Also of note in bug 390734 comment #12... we should add support for NS_THEME_GROUPBOX in widget/src/windows/nsNativeThemeWin.cpp
Status: NEW → RESOLVED
Closed: 19 years ago16 years ago
Keywords: fixed1.9.1
Resolution: --- → FIXED
(In reply to comment #58) > Pushed to mozilla-1.9.1 > http://hg.mozilla.org/releases/mozilla-1.9.1/rev/6fc4052c759f > > I'm closing this bug. If there are additional issues please file a new bug. This doesn't really fix it, as the "tabpanel" appearance has a gradient, at least on XP/Luna. I'd say this bug should just stay open.
Basically, what comment 28 said. Using any background for the caption (no matter if solid or with a gradient) is bound to fail, because the tabpanels background is a moving target.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: robert.bugzilla → nobody
whimboo, I left fixed1.9.1 there for a reason, i.e. that the latest patch (which I guess fixed this bug in some cases, per comment 54) landed on branch.
Keywords: fixed1.9.1
Keywords: fixed1.8
Dao, there are too many of those bugs open which is more confusing because I don't know where to enter more details. I can only see that it is fine on Windows 7 but XP still fails. Vista I don't have right now available. So how we should proceed? bug 390734: Vista bug 433566: XP? bug 349859: using native theme at all?
Henrik, I don't know about the other bugs, but this one should be theoretically easy to solve. All one have to do is to write the code which calculates the width of the area required to display the caption text and draw lines with the appropriate length on the two sides of the caption. This way the caption text is drawn directly on the tab canvas and since there is no line which needs to erased, there is no need for a special background. Now, I would be the first to admit that I don't have a clue on what win32 API to use to achieve this, or if there is some easier way.
Comment in bug 433566 if you have information on how native theming for groupboxes needs to be implemented. Comment in bug 390734 for Vista-specific workarounds. Comment here for workarounds for the caption inside of tab panels, regardless of the OS.
(In reply to comment #64) > workarounds. Comment here for workarounds for the caption inside of tab panels, > regardless of the OS. Dao, based on that comment we shouldn't add the fixed keywords to this bug. Shiretoko, Gran Paradiso and Bon Echo still suffer from that problem on WinXP.
Summary: wrong background for caption in groupbox → wrong background for groupbox caption when used in tab panels
Blocks: 390734
No longer depends on: 433566
This bug was originally opened for the issue with Linux which I hope is now fixed though I haven't verified it. As a matter of fact attachment #194168 [details] shows this affecting Linux without using a tabpanel. I filed Bug 482912 for the remaining issue with Windows XP where tabpanels appear to use a gradient which causes the background for the caption of a groupbox to be incorrect. This way the problem is stated more concisely and anyone trying to fix it doesn't have to try to understand the problem from the different ones that this bug has morphed into over time. If someone could check if this bug is still a problem on Linux please comment back and if it is fixed it might as well be marked as wfm. btw: the difficulty in drawing the line is that this is not only theme dependent it is also dependent on the area the text covers.
(In reply to comment #66) > If someone could check if this bug is still a problem on Linux please comment > back and if it is fixed it might as well be marked as wfm. Robert, could you check this?
I don't know how to reproduce it on Linux, esp. as I am a KDE user and don't have fancy GNOME themes around.
See bug 403753. The caption doesn't have a background on Linux.
Depends on: 482912, 403753
P2 - Polish issue that is in a secondary interface, occasionally encountered, and is easily identifiable. Only really shows up in secondary interfaces, but it clearly and obviously wrong when you view it.
Priority: -- → P2
(switching to whiteboard for polish-relative priorities)
Whiteboard: [polish-hard] [polish-visual] → [polish-hard] [polish-visual][polish-p2]
Priority: P2 → --
Severity: minor → S4

The severity field for this bug is relatively low, S4. However, the bug has 11 duplicates and 15 votes.
:mstriemer, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mstriemer)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(mstriemer)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: