286955 - Rendering error when scolling an Iframe in overflow:hidden div

Status: RESOLVED FIXED

(Core :: Web Painting, defect)

Description

[Hannes]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1

as you can see in the example attatched, there is a rendering error, if you
scroll a div element that contains IFrames, when the overflow:hidden ist
selected. There is no Problem when using overflow:auto

Reproducible: Always

Steps to Reproduce:
1. load the html file attatched
2. see the bug in the right div. The content of the left and right div are
exactly the same.
Actual Results:  
The Iframes are rendered obove the main page containing the DIV tag with
overflow:hidden

Expected Results:  
all the iframes should be hidden. The same as they are on the eft side.

Comment 1

[Hannes]

Attachment: example HTML that demonstrates the bug

Comment 2

[José Jeria]

Seing this with latest trunk build (20050320) as well

Comment 3

[Hannes]

Attachment: Making the iframe 'visibility:hidden' is no workaround

I tried to find a workaround for the given problem.
I made the iframe 'visibility:hidden' and expected that this would help. The
result was Quite strange and unexpected.

Comment 4

[Hannes]

Here is somthing more:
Running the testpage over the time consumed memory increases steadely. On a
windows System.

Comment 5

[tgirmann]

A similar effect occurs when an iframe with "visibility:hidden" is used within a
block with property "display:none" and that property is changed to something
like "display:block" by JavaScript at runtime.
The following HTML page demonstrates that:

Comment 6

[tgirmann]

Attachment: An example page demonstrating the rendering error that occurs when dynamically switching a block element from display:none to display:block that contains an iframe with visibility:hidden

Comment 7

[Hannes]

Attachment: Closing any other window above the Page with the last example. Display Information remains visible

I just had a look at the example 178075.
If you switch between tabs, or close another aplication that was liying above
of Firefox showing the Page of attatchment 178075 does not refresh screen in
the area of the iframe. See the Pic.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The testcase 178075 works for me on trunk. So does 181852. I do see a problem
with 178060 (the first one).

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

When the scrolling view doesn't have a widget of its own, after repainting the
content area we move any child widgets as if they were scrolled. When those
widgets stick outside our clip rect, moving them moves some chunk of page
pixels which shouldn't be moved. The scrolling view code tries to compensate
for this in AdjustChildWidgets by invalidating these moved widgets; they should
repaint themselves with the correct page graphics. Unfortunately in this case
it doesn't succeed because each child widget is exactly covered by its own
child, so the repaint is completely hidden by the grandchild, which is not
itself invalidated. The fix I'm using here is to force the widget and all its
children to be invalidated by hiding it and then showing it again. This isn't a
great solution, but recursively invalidating all widget childen (which would be
apparently more straightforward) probably won't work in all cases, because we
don't always hook up native widget children as nsIWidget children.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 182041 [details] [diff] [review]
fix

relatively simple fix for a rendering-garbage problem, but it's not a
regression.

Comment 11

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 182041 [details] [diff] [review]
fix

a=shaver

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked in

Comment 13

[Martijn Wargers (dead)]

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