Closed Bug 67478 Opened 24 years ago Closed 24 years ago

IFrame leaves crud around its edges

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect)

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: jesup, Assigned: roc)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(9 files)

Testcase
381 bytes, text/html
Details
image of bug
43.66 KB, image/gif
Details
Another image of the bug
43.55 KB, image/gif
Details
iframe content for simple testcase
61 bytes, text/plain
Details
content for simple iframe case
61 bytes, text/html
Details
simplified iframe test case
231 bytes, text/html
Details
This patch seems to do the trick
3.73 KB, patch
Details | Diff | Splinter Review
Testcase IFRAME contents (exercises DOM)
803 bytes, text/html
Details
Testcase (exercises DOM)
1.38 KB, text/html
Details 
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.
Attached file Testcase — 

    
    

    
  

      
      
      
      

        Attached image
          
        image of bug
        — 
      

    


  

    
    

    
  
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.
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.

    
    

    
  
*** 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.
Assignee: pollmann → roc+moz

    
    

    
  
Kevin, I need your review here. Thanks!
Status: NEW → ASSIGNED

    
    

    
  
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED

    
    

    
  
Verified fixed on trunk-build using Win98.

Crud isn't there on any of the testcases.
Status: RESOLVED → VERIFIED

    
    

    
  
*** 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.

Depends on: 70831

    
  
Summary: IFrame leaves crud around it's edges → IFrame leaves crud around its edges

    
  
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: