Closed Bug 345609 Opened 13 years ago Closed 12 years ago
[FIX]Themes can no longer style print preview scrollbars anything but "native"
What I already noted before on Firefox is also true for SeaMonkey on trunk: the scrollbars, scrollbarbuttons, and the scrollbar corner are not themed any more. That means they appear white. As far as I know this is OS/2 only, because nobody replied to my multiple posts in the newsgroup about this. I now discovered some old nightlies and determined that the regression occurred between 2006012505 and 2006012605, so I searched on bonsai like this (giving it a few more hours as timezone buffer): http://bonsai.mozilla.org/cvsquery.cgi?module=SeaMonkeyBrowser&date=explicit&mindate=2006-01-25+01&maxdate=2006-01-26+08 Unfortunately, that didn't turn up something that to me immediately looked like a possible cause and still leaves quite a few big checkins in the possible range.
roc, your large checkin for Bug 317375 falls into that timeframe. Do you think that one of the changes could have caused this problem back then? I see one checkin to nsGfxScrollFrame.cpp that even has some comments about painting scrollbars and scrollcorner... If you have any hints where I could put some debug output, please let me know.
Happens on WinXP, too. I thought this was known (and filed), and just ignored because it was SeaMonkey, but here's hope!
OS: OS/2 → Windows XP
Huh, there is bug 344039 (which I obviously was too tired to find last night) but that explicitely says that it only occurs in Thunderbird.
OS: Windows XP → All
I don't see this. I'm using a SeaMonkey 7/22 build and XP. Under what SeaMonkey theme is this happening? (I filed bug 187916 three and a half years ago because Modern doesn't theme scrollbars at all - which even though it themes all other UI elements - but I don't think this can possibly be what you're referring to because there's no regression involved in that.)
Ah! The screenshot clears everything up. It's not that it's no longer themed per the OS theme, it's that it's no longer themed per the Modern SeaMonkey theme.
Product: Mozilla Application Suite → Core
Summary: Print preview scrollbars are unthemed since 2006-01-26 → Print preview XUL scrollbars are unthemed since 2006-01-26
*** Bug 344039 has been marked as a duplicate of this bug. ***
It looks like this issue is caused by the "Print background" option - if you turn that on then scrollbars display properly. Is there any way for chrome CSS to override that option or will this need to be fixed in core code? Note that the Classic and *Stripe themes use nsITheme to draw their backgrounds and therefore do not appear to be affected, except for the scroll corner.
(In reply to comment #8) >Note that the Classic and *Stripe themes use nsITheme to draw their backgrounds Well, not on some platforms, e.g. OS/2
I bet the issue is that nsBoxFrame::Paint used to not follow the "paint background" setting, but now it just uses nsDisplayBackground to paint. This does call HonorPrintBackgroundSettings() on the frame, but all frames return PR_TRUE. Should nsBoxFrame be returning false?
Assignee: general → roc
Oh, and I see no way for chrome to affect this behavior.
Or maybe just nsScrollbarFrame and nsSliderFrame, although there's still the issue of the buttons.
Perhaps nsBoxFrame::HonorPrintBackgroundSettings() should return false for frame descendants of the print preview viewport scrollbars.
Flags: blocking1.9a1? → blocking1.9+
Target Milestone: --- → mozilla1.9beta1
This is not just about 'no background', but all themes not using the -moz-appearance have the problem of wrongly sized scrollbars...
Works for me on Linux, 2007-10-06-04-trunk nightly and pretty current debug build.
David, are you using a non-default theme? And do you have background printing disabled? This problem only affects themes that don't use native-themed widgets.
Er, sorry, never mind. Somebody who understands what the bug is should update the summary, though, since it's currently wrong.
Given the settings mentioned in Comment #18, should this really block beta?
Damon, the "background printing disabled" setting is the default. For the other... this will break with any theme not using OS-appearance scrollbar styling. On operating systems where we have no OS-appearance styling (e.g. OS/2, where the bug was first encountered) it breaks with all themes. Whether you're willing to block beta for it is a good question, but the fix will have to come in core code, not on the theme side. Frankly, I think we should just return false for any frame whose content is in a native anonymous subtree. That might be an easier test than "descendants of the print preview viewport scrollbars", but will also keep the styling on scrollbars in the document itself. Not sure whether that's desirable.
Summary: Print preview XUL scrollbars are unthemed since 2006-01-26 → Themes can no longer style print preview scrollbars anything but "native"
That probably is desirable, so I agree that's the right approach...
This should definitely not block beta! I don't know how that happened.
OK. Thanks roc. Targeting for the next release.
Target Milestone: mozilla1.9 M9 → mozilla1.9 M10
I'm not even sure it should block 1.9, to be honest. But it's relatively easy to fix so we should probably still fix it.
Flags: blocking1.9+ → blocking1.9-
We need a separate bug on comment 15, since it doesn't have anything to do with the problem this bug is about.
12 years ago
Priority: -- → P2
Summary: Themes can no longer style print preview scrollbars anything but "native" → [FIX]Themes can no longer style print preview scrollbars anything but "native"
Regarding comment 15 and comment 27: See bug 378272. The issue may be very much in the same direction. That in the print-preview display, the non-native scrollbars get some scaling applied that just like the suppression of background-color should not happen.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
12 years ago
Depends on: 400459
You need to log in before you can comment on or make changes to this bug.