177365 - {inc} Page not reflowed correctly when image arrives and image size becomes known

Status: REOPENED

(Core :: Layout: Block and Inline, defect, P3)

Description

[Daniel Bratell]

The web page at http://elftown.lysator.liu.se/ is layout wrongly when fist
loaded over the net. The text that should be below the picture overlap the
picture and the form that should be on top of the image is below it. A forced
reflow by resizing the browser corrects all errors. If height and width is
specified on the image the page is also correctly displayed, so it seems to be a
problem with reflowing the page when the image arrives and the height and width
becomes known.

This seems to be a problem in Mozilla 1.0 as well as current builds from CVS so
it's no new problem. 

I will attach screenshots.

Comment 1

[Daniel Bratell]

Found a better component -> Layout, positioning.

Comment 2

[Daniel Bratell]

Attachment: Screenshot - Wrong layout at first load

Comment 3

[Daniel Bratell]

Attachment: Screenshot - Correct layout after a forced reflow

Comment 4

[Boris Zbarsky [:bzbarsky]]

There is no positioned content on this page... Daniel, what improvements do you
think should be made to the component description to prevent confusion like this?

I suspect this is a floater issue, but a minimal testcase is needed.

Comment 5

[Daniel Bratell]

Oh, I was under the impression that it had that kind of positioning. Now I see
that it's just two divs like this:

<div>Text text text text text...</div>
<div style="margin-top: -540px"><img src="..."></div>

Comment 6

[Boris Zbarsky [:bzbarsky]]

sounds like margin-collapsing troubles..

Comment 7

[Jeroen Kruis]

Page at the URL has changed.
If anyone has the original html, I'll make a testcase out of it.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Daniel, any chance of a testcase that shows the problem?  The url in the URL
field is timing out for me....

Comment 9

[Daniel Bratell]

I know that one of the maintainers did a copy of the page before implementing a
workaround. I've been waiting to hear from him so there's still a chance, but I
hasn't got it.

Comment 10

[Tom Gilder]

Attachment: Testcase

My guess is the original page was something like this (I came across this bug
on one of my own pages a few days ago).

Comment 11

[Dean Peterson]

Tip on using the testcase from comment 10:

If I clear the cache and open the attachment, the problem does not occur (the
red text displays correctly at the bottom of the page.)  However, if I clear the
cache, right-click on the attachment, and choose "Open Link in New Window", the
problem occurs (the red text is rendered just below the bottom of the browser
window, but in the middle of the document.)  I don't know why.

Oddly enough, if I then open another tab on the new browser window so that the
tab bar displays, clear the cache again, and refresh the attachment, the red
text renders just ABOVE the bottom of the browser window (still in the middle
of the document, though.)

Comment 12

[Chris "SoopahMan" Moschini]

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

Comment 13

[Chris "SoopahMan" Moschini]

My attempt to analyze what's happening here:

1) Mozilla loads a page that contains both:
 * Img tags with no width/height in a box/tag, "boxImg."
 * Content in a separate box/tag, "boxShift," that must be positioned below or
to the right of boxImg.

2) The boxImg is rendered smaller than it will eventually be, because the images
are rendered with a small default width and height. boxShift is rendered to the
right or the bottom, but not as far right/down as it will eventually need to be.

3) Mozilla loads each image, adjusting its dimensions and reflowing as needed.
Within boxImg, things shift appropriately, and the resulting dimensions of
boxImg itself shift appropriately. BUT - boxes outside boxImg do not shift as
needed. Their calculated positions are not updated.


This would account for why the bug isn't exhibited with cached images - the
dimensions are never updated to cause a broken reflow. And it accounts for why
the exact same problem can be reproduced with float or position absolute (note
that only float: right and position: absolute combined with bottom or right can
do it).

A brute force fix would simply reflow the entire document each time an image's
dimensions are learned. If there is some way of flagging Elements that are
relatively positioned to the right or bottom (float: right or position: absolute
for example), then the list of Elements to be recalculated can be made shorter
in most cases.

Comment 14

[IrYoKu]

I think that same problem arises when an element with a style like "position:
absolute; left: 200px; top: auto" is below of an image. The element is
positioned -imageHeight from the correct top position. A page refresh seems to
fix the problem.

Comment 15

[Richard Weaver]

(In reply to comment #13)

I was going to post this bug myself but you're already on the case. One extra
thing I have noticed which may or may not be obvious: this bug is also evident
if the image can't be found and ALT text is displayed instead - absolutely
positioned elements stay where they are whilst everything else reflows. If
you're testing this, using a broken image link has the advantage that nothing
gets cached so the bug is reproducable every time.

Comment 16

[Michael Winter]

I've also recently encountered this bug on WinXP. An additional demonstration 
can be found at http://www.mlwinter.pwp.blueyonder.co.uk/mozilla-bug-177365/

This particular test case adds a new dimension to the problem: if the 
implicitly-sized image isn't in a separate block element (the third case), there 
are no layout issues.

I also thought I'd add that this issue affects Firefox, in addition to Mozilla. 
However, Mozilla 1.0 (2002053012) seems to be unaffected, unlike all of the more 
recent versions I have (up to 1.8a5 2004111204).

Comment 17

[Jeroen Kruis]

Attachment: Screenshot - page before reflow

Getting the right and wrong states from the testcase mentioned in comment #16
is easy. This screenshot shows the third state: before the images are loaded.

One thing I noticed: the first situation DOES reflow correctly when the image
is missing.

Comment 18

[Martijn Wargers (dead)]

I can see the bug in the Testcase, using:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041114
But I can't see it anymore, using:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041115
Firefox/0.9.1+
That bug was fixed by bug 261064.

But comment 4 mentions that this bug wasn't about positioned content at all. So
that would mean that was an unrelated testcase. 
The original problem, I'm not seeing at all.

Comment 19

[Samuel Sieb]

I don't see the problem using these testcases on Linux, but I have a different
one that seems to be a similar problem.  If you agree that this is the same
issue, then you can change OS to ALL.

See http://sieb.net/bugs/bug177365.php for the testcase.  Someone else created
the testcase, but I made it so that it always shows up without having to restart
the browser.  The problem appears directly related to the images.  If I put the
size in the <img> tags, there is no problem, but if the size is unknown, it lays
out incorrectly.  Once the image is cached, the image size is known, so
subsequent reloads would not make a difference.  However, I've made the images
uncachable, so a reload always shows the problem.  You can resize the window to
see the proper layout.

Comment 20

[Eyal Rozenberg]

Indeed, I no longer see this problem with the existing testcase. However, I do
not see any layout change in http://sieb.net/bugs/bug177365.php when I reload -
the plus images are still at the right edge of the window. I do however continue
to see the problem with the testcase of bug 195368; is it a dupe of this bug?
Should it be closed and this one remain open? Perhaps the other way around?

(ps, I'm using build 2005-01-28 04 on WinXP)

Comment 21

[Samuel Sieb]

Please read the text more carefully.  A reload will reset it to the wrong
layout, you need to resize the window to see the change.

Comment 22

[Eyal Rozenberg]

Resizing doesn't change anything either. Everything's still at the right edge.

Comment 23

[Samuel Sieb]

The images should be at the right edge.  It's the lines at the left that move. 
The bottom one should be lined up with the second one.

Comment 24

[Andreas Lange]

I've checked the attached testcase,
http://www.mlwinter.pwp.blueyonder.co.uk/mozilla-bug-177365/ and
http://sieb.net/bugs/bug177365.php on a current trunk build without seeing the
problem. 

Can anyone else reproduce this? Oterwise this could be closed. There are a few
other bugs dealing with images and floats that still are relevant.

Comment 25

[marco]

(In reply to comment #24)

> Can anyone else reproduce this?

I ran my test case with the latest nightly build and the problem is still there. 
This test case is much simpler and reproduces the behavior with only a few lines 
of HTML:

http://www.earthli.com/users/marco/bugs/firefox_float_refresh_bug.html

I used the "Deer Park" Firefox build with user agent <Mozilla/5.0 (Windows; U; 
Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050713 Firefox/1.0+>

Comment 26

[Samuel Sieb]

My testcase is still broken as well on Seamonkey just built from CVS.

Comment 27

[Martijn Wargers (dead)]

Attachment: Testcase

Testcase based on testcase from comment 25

Comment 28

[Martijn Wargers (dead)]

Attachment: Testcase2

This testcase is based on http://sieb.net/bugs/bug177365.php from comment 24.

Comment 29

[Steve England [:stevee]]

In testcase 2, the links are always right under each other, irregardless of whether reload or shift-reload is used, in:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120606 Minefield/3.0a (pre-reflow branch)
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120804 Minefield/3.0a1 (post-reflow branch)


In testcase 1, the green blocks are always under each other, irregardless of whether reload or shit-reload is used, in:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120606 Minefield/3.0a (pre-reflow branch)
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120804 Minefield/3.0a1 (post-reflow branch)

However, the text in this testcase says they should be *next* to each other.

Comment 30

[Mats Palmgren (inactive)]

Bug still occurs in post-reflow branch build, SeaMonkey 2006120801 on Linux.
Shift-Reload/Reload a few times of attachment 195138 [details] results in the blocks
being next to each other sometimes and above each other sometimes.

Comment 31

[Ryan VanderMeulen [:RyanVM]]

Testcase2 WFM and Testcase1 is the same as bug 257552, which has a more reliable testcase. Resolving WFM.

Comment 33

[Ryan VanderMeulen [:RyanVM]]

FWIW, Testcase2 was fixed between the 10-16-05 and the 10-17-05 nightlies. There were a few reflow-related checkins during that period, but I'm not going to take the time to figure out which of them specifically fixed it.

Comment 34

[Ryan VanderMeulen [:RyanVM]]

Attachment: image for new testcase

Comment 35

[Ryan VanderMeulen [:RyanVM]]

Attachment: Testcase2a

New testcase

Comment 36

[Ryan VanderMeulen [:RyanVM]]

There must be some kind of timing issue here, because this bug is still reproducible when using a non-inlined image. To reproduce, open testcase2a and hit shift+reload to see the two lines misrender still.