bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

IFrame leaves crud around its edges




Layout: HTML Frames
17 years ago
17 years ago


(Reporter: jesup, Assigned: roc)




Firefox Tracking Flags

(Not tracked)




(9 attachments)



17 years ago
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.

Comment 1

17 years ago
Created attachment 24235 [details]

Comment 2

17 years ago
Created attachment 24236 [details]
image of bug

Comment 3

17 years ago
Created attachment 24238 [details]
Another image of the bug

Comment 4

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

Comment 5

17 years ago
Oops, that should be bug 49779.
I am not seeing this in a fresh Linux build I just pulled.

Comment 7

17 years ago
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

Comment 9

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

Comment 10

17 years ago
This is definitely present on Linux 2001-02-13-03.
Created attachment 25211 [details]
iframe content for simple testcase
Created attachment 25212 [details]
content for simple iframe case
Created attachment 25213 [details]
simplified iframe test case


17 years ago
OS: FreeBSD → All
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.

Comment 16

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

Comment 17

17 years ago
*** 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.

Comment 23

17 years ago
BodyFixupRule is my problem - I'll take care of it if you want. That thing has
plauged moe for some time now... Please advise.
Created attachment 25721 [details] [diff] [review]
This patch seems to do the trick
Created attachment 25722 [details]
Testcase IFRAME contents (exercises DOM)
Created attachment 25723 [details]
Testcase (exercises DOM)
OK, I think we're in good shape with that patch.

Comment 28

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

Comment 29

17 years ago
Robert, as this bug/fix are in your area, can I reassign this bug to you?
My apologies, I should have taken it already.
Assignee: pollmann → roc+moz
Kevin, I need your review here. Thanks!
patch looks good.
Fix checked in.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 34

17 years ago
Verified fixed on trunk-build using Win98.

Crud isn't there on any of the testcases.

Comment 35

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

Comment 36

17 years ago
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.
Depends on: 70831


17 years ago
Summary: IFrame leaves crud around it's edges → IFrame leaves crud around its edges
You need to log in before you can comment on or make changes to this bug.