Closed Bug 575615 Opened 14 years ago Closed 14 years ago

Messagepane does not display default background color in Shredder

Categories

(Core :: Web Painting, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Tracking Status
blocking2.0 --- beta3+

People

(Reporter: u382332, Unassigned)

References

Details

(Keywords: regression)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100629 Minefield/4.0b2pre Firefox/3.6 Build Identifier: The messagepane does not display default background color. It displays a sort of gray dialog background. Reproducible: Always Steps to Reproduce: 1.Using three-pane view and start page turned off. 2.Start or restart Shredder with messagepane open. 3. Actual Results: Unusual background color display. Expected Results: Display default background color. Regression Works: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a6pre) Gecko/20100627 Shredder/3.2a1pre Not working: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a6pre) Gecko/20100628 Shredder/3.2a1pre
Also observed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100629 SeaMonkey/2.1a3pre, with mailnews.start_page.enabled = false and mailnews.remember_selected_message = false, the Mail & News window shows dialog background color now when opened. Jim, this suspiciously coincides with the bug 574599 checkin, is this related?
Keywords: regression
Version: unspecified → Trunk
The clip children style remove a child widget's screen area from any paint message sent to the parent. If the effected views in these cases are children and they are opaque views, it's probably not bug 574599.
(put that out there in case anyone want's to investigate, I'll get to this at some point!)
I can't get dynamically inserted content to show up either, so I'm guessing there that the view isn't getting shown correctly? While I mention it I notice that the window now visibly maximises rather than opening maximised. Is that relevant?
(In reply to comment #1) > this suspiciously coincides with the bug 574599 checkin, is this related? Actually, I matched the regression range wrong. The 20100627 build was still ok, so it can't be that bug, but the following changeset fits date-wise: http://hg.mozilla.org/mozilla-central/rev/7ad36412775e (bug 574690), having Various patches on "Prevent DocumentViewer from showing in certain situations"
That sounds more serious. What app are we playing with here? STR?
Blocks: 574690
Status: UNCONFIRMED → NEW
Ever confirmed: true
Fairly simple, use Shredder (Thunderbird) or SeaMonkey trunk build: 1) Set prefs as stated in comment #1. 2a) Start Shredder, or 2b) start SeaMonkey and then open the Mail/News window (Ctrl+2). 3) Watch the pane below the message list, it should have document background by default but has dialog background now, apparently isn't painted at all. If step #3 doesn't work right away, select a folder (e.g., Inbox) if you ended up in the account view, then retry. I'm not sure about Neil's comment #4 with dynamically inserted content, were you using some about:... URL in the start-up page rather than the usual one?
A related Fx regression might help too if anyone has any ideas on where it might manifest.
Blocks: 576096
No longer blocks: 574690
Blocks: 574690
blocking2.0: --- → ?
Possibly related post in mozilla.dev.usability? Stanimir Stamenkov wrote: > I have the following preferences: > > browser.display.use_system_colors=true > browser.startup.page=0 > > but I observe when I start latest Minefield 4.0b2pre on Windows XP (and > number of builds in the last week or two) I get a pure white background, > although my system preference for Window color is silver (#C0C0C0):
It could really be a Fx regression <http://groups.google.com/group/mozilla.dev.usability/msg/223e99ebe2a19cca>: > ... I guess the Firefox devs has tried to > hide the problem of not painting the browser area properly where it > gets filled with the underlying Dialog color of the xul:tabpannels > by making it white simulating a blank page, which however doesn't > look nice on all systems.
Don't know if this would be of any help, but the rule: tabpanels { background-color: white; } has been added to "tabbrowser.css" in http://hg.mozilla.org/mozilla-central/rev/aaa00046139e (Bug 543306). I also notice in Firefox 3.6 the xul:tabpanels in "chrome://browser/content/browser.xul" has its styles from the following style sheets: || Rule || File || | tabpanels | chrome://global/content/xul.css | | tabpanels | chrome://global/skin/tabbox.css | | tabpanels | chrome://browser/skin/browser.css | while in latest Minefield 4.0b2pre: || Rule || File || | tabpanels | chrome://global/content/xul.css | | tabpanels | chrome://global/skin/tabbox.css | | tabpanels | chrome://browser/content/tabbrowser.css | The change "chrome://browser/skin/browser.css" -> "chrome://browser/content/tabbrowser.css" dates back to Jan 2008 http://hg.mozilla.org/mozilla-central/rev/608eb72f57b2 (Bug 410128).
The problem here though is that the pane background doesn't seem to have any color whatsoever when opening and just appears with default dialog background. Thus, I'm a bit struggling to see these two issues as being related.
Bugs 410128 and 543306 may are not related as their changes are dated back enough. The issue I see with Minefield is the browser area doesn't get painted and the underlying xul:tabpanels background shines through. I see just the same with Shredder here. The message pane area doesn't get painted and the underlying xul:tabpanels background shines through. The browser area in Minefield starts to get painted correctly with new tabs opened or <about:blank> explicitly opened in the tab. The message pane area in Shredder starts to get painted after I open a message. May be it is related to rendering of the <about:blank> document.
(In reply to comment #0) > Works: > ... Gecko/20100627 Shredder/3.2a1pre > > Not working: > ... Gecko/20100628 Shredder/3.2a1pre The regression range I've identified for my Minefield issue is just the same.
This should be fixed in tomorrow's nightly.
(In reply to comment #1) > Also observed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:2.0b2pre) > Gecko/20100629 SeaMonkey/2.1a3pre, with mailnews.start_page.enabled = false and > mailnews.remember_selected_message = false, the Mail & News window shows dialog > background color now when opened. Yes, this case is fixed with Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100717 SeaMonkey/2.1a3pre (no Thunderbird nightly yet).
(In reply to comment #16) > (In reply to comment #1) > > Also observed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:2.0b2pre) > > Gecko/20100629 SeaMonkey/2.1a3pre, with mailnews.start_page.enabled = false and > > mailnews.remember_selected_message = false, the Mail & News window shows dialog > > background color now when opened. > > Yes, this case is fixed with Mozilla/5.0 (Windows; Windows NT 5.1; en-US; > rv:2.0b2pre) Gecko/20100717 SeaMonkey/2.1a3pre (no Thunderbird nightly yet). great, thx! Please reopen if you see any issue additional issues.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Verified fixed in Shredder as well. Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100718 Shredder/3.2a1pre
Status: RESOLVED → VERIFIED
blocking2.0: ? → beta3+
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.