157444 - {inc}clear (from <br clear="all">) lost on incremental reflow

Status: RESOLVED FIXED

(Core :: Layout: Floats, defect, P1)

Description

[Jens Fallesen]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1a+) Gecko/20020714
BuildID:    2002071420

When going to the listed URL, the page is rendered incorrectly (see attached
screen shot, gc-1stload.png) with some text appearing in the top bar. Reloading
the page solves the problem, though sometimes two reloads are necessary.

Also seen on fairly recent Windows builds.


Reproducible: Always
Steps to Reproduce:
1. Go to this URL: http://www.geekculture.dk/arkiv.php3?reviewid=1230
2. Notice how it looks bad
3. Push the reload button
4. Notice how it looks good (if not, repeat from 3)

If there is no problem on first load, try selecting other articles from
http://www.geekculture.dk/ and see if it happens. (Sorry, the contents of the
site are in Danish only.)

Actual Results:  First load looks weird (as in gc-1stload.png), second load is
fine (as in gc-2ndload.png).


Expected Results:  Even first load should look fine.

I have verified the source code on first and second load and this is the very
same code so the server is not generating different pieces of code.

This happens using both classic and modern theme. Not tested with other themes.

Comment 1

[Jens Fallesen]

Attachment: First load of demo page, looking not too good

Comment 2

[Jens Fallesen]

Attachment: Demo page as it looks after a reload

Comment 3

[Eli Friedman]

I don't see it in Moz 1.1alpha (WinME).  Regression?

Comment 4

[Andrew Schultz]

Attachment: Simplified testcase

Comment 5

[Andrew Schultz]

marking NEW
regression between linux builds 20020426 and 20020428.  bug 138057 looks to be a
decent candidate for causing this.

changing OS to Linux to get more attention.

Comment 6

[adrian]

This WFM
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20020923

The original linked site lays out fine--it looks like the attached gif showing
correct layout.

The testcase also lays out fine, after I altered it to point to gifs that exist.

Just a guess, but perhaps it was fixed by 154780? bug 161686 was fixed by that
patch, and it sounded a lot like this one.  It was over lapping tables, which
were fixed by a reload.

Reporter: Can you reproduce this on the latest build and/or 1.2b?

Comment 7

[Andrew Schultz]

> The testcase also lays out fine, after I altered it to point to gifs that exist.

the testcase should be ok (and it's not) even if the gifs don't exist.  Did you
point it at local gifs or gifs off the network?  I doubt this will show up with
local or even cached images.

the url also looks fine.  it isn't correct with an older build (but is not
correct in a different way, so something there probably changed).

tested with linux trunk build 20021028

Comment 8

[Jerry]

wfm with 20021026 build on win2k.

mark it as wfm.

report, if you use more recent build, still can reproduce the problem to acess
the url, feel free to reopen it.

Comment 9

[Jens Fallesen]

Sorry for not reporting back before now--I have been doing way too many other
things recently. I am unable to reproduce the problem in any recent build so I
can only agree with the WFM.

Comment 10

[Andrew Schultz]

the testcase is NOT worksforme and so this bug is not WFM.  I dug up the
original page and will attach it.  It also still exhibits the same problem.

Comment 11

[Andrew Schultz]

Attachment: Original page (7/14/2002)

with this, you see the bug on first load, or have to hit shift-reload.	simple
reload fixes the layout.

Comment 12

[adrian]

Attachment: second testcase

This testcase is related to the first one by Andrew Schultz.  However it
demonstrates the jumping around of the floaters, as described by the original
reporter.  This means that we can see the incorrect layout on the first load,
or a shift-reload, and see it correct itself on a reload.

I also removed one of the tables, to make the testcase more reduced.
So the test case consists of a floated image, a "br" tag, and an aligned table
with a gif in it.


Steps to use:
1: Make sure that your browser window is at least 650 pix wide.
2: Click on the testcase.
3. See that the bugathon gif is near the top of the page.
4. reload.
5. See the bugathon gif jump down.
6. shift-reload.
7. See the bugathon gif jump up.

Comment 13

[Andrew Schultz]

adrian: I'm think your testcase might be showing a different bug.  Note that in
the original page and the first testcase, the second float (the second table) is
positioned properly.  In your testcase, the second float is what is badly
positioned (although the effect there is the same)

also, the first testcase does not show any "jumping" simply because the <img>s
are invalid.  If they existed, things would "jump"

Comment 14

[Andrew Schultz]

Attachment: testcase without tables

In the spirit of adrian's testcase, I tried removing/replacing the tables and
came up with this.  The effect is the same.

Comment 15

[Andrew Schultz]

==> Layout/Floats

Comment 16

[Hixie (not reading bugmail)]

Well, attachment 105439 [details] and attachment 105450 [details] both work fine for me, but I see
the bug with attachment 91300 [details]. A reflow moves the text to the right place.
Therefore I am unobsoleting that testcase.

Note - the original page has changed.

Comment 17

[Michal Kubecek]

Last two testcases (2002-11-07) render correctly if one uses local file, ie.
file:/... (both for html and images). Tested with Mozilla 1.3b on Linux-ix86.
When I tried a copy on local Apache (http://127.0.0.1/...), "second testcase"
renders incorrectly for the first time and then correctly after both reload and
shift-reload. One has to clear browser cache and restart Apache for the
incorrect rendering to reappear.

Comment 18

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

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

Comment 19

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

Attachment: simplified testcase

Comment 20

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

Attachment: patch

Comment 21

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

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

Comment 22

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

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

Comment 23

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

Taking bug.

Comment 24

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

Comment on attachment 118228 [details] [diff] [review]
patch

This isn't pretty, but it fixes one of our most serious incremental reflow
bugs.  Note that |needToRecoverState| can never be true for the first line, so
|--line| is safe.

Comment 25

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

Fix checked in to trunk, 2003-03-25 07:24 PST.

Comment 26

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

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

Comment 27

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

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