FreeBSD 4.1 20010131xx (Probably applies to other OS's as well) When I show this testcase (attached), I see an ad, with 'advertisement' above it. In the border around the ad and under advertisement, I see semi-random crud; either other parts of the page or bits of the menu bar, etc. In particular I see it if I switch to another virtual desktop screen and back, but I also see it simply rendering the page. Part of the question is _why_ any of that is drawn there in the first place - it's not simply background that mozilla forgot to erase/redraw.

Caused by the checkin for bug 49799 (not clearing backbuffer to white).

Oops, that should be bug 49779.

I am not seeing this in a fresh Linux build I just pulled.

I still see it in a freshly built tree from the tip, with both the default viewmanager and scary_view_manager. The easiest way to make the crud appear is to slide across the expanded menus.

Yeah, I just discovered my build process isn't doing what I think it is

*** Bug 67821 has been marked as a duplicate of this bug. ***

This is definitely present on Linux 2001-02-13-03.

I am seeing the problem on WIN32, setting OS to ALL.

OK, here's the situation. nsViewportFrames do not paint their backgrounds, but because the style system assigns them a non-transparent background color, the associated view is marked opaque. Consequently the view manager thinks it doesn't need to clear the backbuffer or issue a warning. I tried changing the :viewport rule in html.css to say "background-color: transparent ! important". It fixes all instances of this bug, and I don't see any other problems, but I'm not sure what I might have broken in the process. The effect is that nsViewManager notices that nothing is going to paint the background, and paints its own gray background as an emergency measure. It also spews out annoying "XXX: Using final transparent rect" messages. As far as I can tell, ideally in these IFRAME test cases the contained documents would be transparent. But implementating that would be really hard, probably requiring one view manager handling all the documents in a window. Worth doing, but a big job.

*** Bug 68788 has been marked as a duplicate of this bug. ***

*** Bug 68932 has been marked as a duplicate of this bug. ***

Ian, can you OK this change?

Kevin, what do you think? I seem to recall the white!important rule was put in there for a reason, but I can't seem to track it down...

Hold on. If we change these rules, then when the user has "use document colors" checked and the document doesn't specify any colors, it comes out transparent. Apparently the background IS painted for the primary document but not for IFRAME documents. The nsCanvasFrame derives from nsHTMLContainerFrame and therefore paints its background. Hmm.

Hmm. Now it looks like the canvas isn't inheriting the background correctly in non-scrollable documents. Could be a problem in nsCSSFrameConstructor.

OK, now I think the problem is in nsHTMLBodyElement's BodyFixupRule::MapStyleInto. If the BODY and HTML backgrounds are transparent, it still pushes the BODY background into the canvas, making it transparent. This is wrong. If the HTML and BODY backgrounds are both transparent, then we should use the presContext's default canvas background. I think this works OK for scrolled shells because the scroll frames paint the default background instead of the canvas.

BodyFixupRule is my problem - I'll take care of it if you want. That thing has plauged moe for some time now... Please advise.

OK, I think we're in good shape with that patch.

This looks good to me. r/sr=attinasi (for patch 25721)

Robert, as this bug/fix are in your area, can I reassign this bug to you?

My apologies, I should have taken it already.

Kevin, I need your review here. Thanks!

patch looks good. r=kmcclusk@netscape.com

Fix checked in.

Verified fixed on trunk-build using Win98. Crud isn't there on any of the testcases.

*** Bug 70967 has been marked as a duplicate of this bug. ***

According to dbaron, the fix for this bug was no correct. I'm not reopening it though, just marking the dependency for the record. See bug 70831 for more info.