180931 - insufficient invalidation after dynamic reflow

Status: VERIFIED FIXED

(Core :: Web Painting, defect, P1)

Description

[Per Ångström]

This page has some dynamic content that affects the entire page when displayed
or hidden. When that happens, the display is not updated properly, leaving ugly
traces of the old display to the right.

How to reproduce:
1) Open the URL in a sufficiently wide window.
2) Click the link labeled "+ Avdelningar" in the left column, to make the
dynamic content appear.

Desired result:
The page should have a normal appearance after reflowing to make room for the
dynamic content.

Actual result:
To the right, you will see traces of how the page looked before reflowing.

----

A similar problem is exhibited by <http://www.autark.se/menytest0.html> (click
on any of the links labeled "+ Innehåll").

It seems that Netscape 7 is not as badly affected as Mozilla. Internet Explorer
and Opera 7b1 don't have this problem.

I have an idea that my use of 'max-width' has something to do with this bug.

Discovered in "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021115
Phoenix/0.4". Seen in Mozilla on Linux, and in Phoenix and K-Meleon on Windows 98.

Comment 1

[Per Ångström]

In 1.3b-20030110, I can no longer reproduce the problem on the original URL,
<http://www.autark.se/dynresize_example.html>. However, it it still reproducible
on <http://www.autark.se/menytest0.html> (URL updated accordingly).

Using an older build, I have seen similar symptoms on ordinary pages, when
accessing <http://www.autark.se/> on a slow analog line.

Comment 2

[Andrew Schultz]

Attachment: testcase

testcase demonstrates the bug with linux trunk 20030111
after clicking 'foo', the second line is moved down and the previously-hidden
line is displayed, but the second line is not completely erased from the its
previous position.

Comment 3

[Andrew Schultz]

if you have trouble reproducing this bug, try making your window wider (1000+)

Comment 4

[Per Ångström]

No improvement in Mozilla 1.4a-20030401. The partial improvement mentioned in
comment #1 has vanished.

Comment 5

[Per Ångström]

The testcase, and <http://www.autark.se/menytest0.html>, work OK in
1.4b-20030429 Mozilla Firebird/Linux. However, my original testcase,
<http://www.autark.se/dynresize_example.html>, is now reflown badly.

Comment 6

[Andrew Schultz]

the dynresize_example works fine for me.  are you seeing the original bug when
you click or a different one?

Comment 7

[Per Ångström]

Attachment: Screenshot that demonstrates the bug on Firebird 0.5-20030429.

It's the original bug I see. As you have already noted, the window has to be
quite broad, enough to let max-width kick in.

I just downloaded Mozilla 1.4b-20030502 and tried it on Win98: same problem.

Comment 8

[Per Ångström]

Attachment: More elaborate testcase

Comment 9

[Per Ångström]

Attachment: A simpler testcase (no tables, only spans).

Comment 10

[Boris Zbarsky [:bzbarsky]]

Looks like we're not invalidating enough of the line....

Comment 11

[Per Ångström]

No improvement in 1.4rc3.

Comment 12

[Per Ångström]

The bug survived into Mozilla 1.4 and Netscape 7.1.

Changed summary.

Comment 13

[Aaron Kaluszka]

Reproduced on Firebird 20030714.  I have similar problems just loading Yahoo!
and I've seen it happen on different machines.  Is this the same bug?

Comment 14

[Per Ångström]

The bug is still there in 1.5 beta.

Re seeing the bug on Yahoo: I can't reproduce it on <http://www.yahoo.com/>.
Given that Yahoo's front page doesn't use much in the way of dynamic content,
you are probably seeing a problem on some other page - please be more specific.

Comment 15

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

Attachment: fix

Here's a fix for this bug, with some cleanup added too (move
nsFrame::Invalidate to nsIFrame and remove its aPresContext parameter, and add
a usable + operator to nsRect).

The basic problem is that the auto-margin block is positioned at X=0, then
Reflow is called on it, then PlaceBlock repositions it to the correct X offset.
During its Reflow the auto-margin block does a few Invalidates --- but they
invalidate the wrong area because its X is temporarily 0!

There are a few possible solutions. The solution I have implemented here is to
have FinishReflowChild repaint the entire child frame if it moves. That fixes
this bug.

I suspect this may not be a complete solution; I'm worried about the case where
the block shrinks so that the invalidates during Reflow go to the wrong place,
and the new overflow area isn't big enough to cover the area that should have
been invalidated. Fixing that might require invalidating the old block overflow
area if we move the block when we do the mFrame->SetPosition in
nsBlockReflowContext::ReflowBlock. But it's not clear we can easily get the old
overflow area there. Or maybe there's a way to get around this temporary block
repositioning behaviour, so that we just don't move the block until we know its
final offset.

Comment 16

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

CCing dbaron for comments.

Comment 17

[Aaron Kaluszka]

No, the Yahoo thing was a different bug, which was fixed several weeks ago.

Comment 18

[Per Ångström]

No improvement in 1.6 beta.

Comment 19

[Per Ångström]

The bug survived into Mozilla 1.6.

Comment 20

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

sr as well, although double-check that the overflow area always includes the
frame bounds by this point

Comment 21

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

Fix checked in.

Comment 22

[Per Ångström]

Looks good in Mozilla 1.7a. Marking as VERIFIED.