148621 - {inc} table does not reflow when unknown image size are known

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect, P4)

Description

[Sven Krohlas]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.0.0) Gecko/20020601
BuildID:    2002060109 branch and cvs-trunk



Reproducible: Always
Steps to Reproduce:
1.got to http://www.webmin.com/webmin/
 ->you see, depending on your screen with (I tried 1280x1024) a horizontal
scrolbar on the bottom of the page
2.reload
 -> you won't see the scrollbar, but you can see the whole site, so it wasn't needed

I think this is because of the navigation links (Webmin, Documentation, ...),
which are actually graphics and don't have a width and height attribute.

Comment 1

[R.K.Aa.]

Linux, current trunk CVS:

On first load the whole page lays out far too wide. So the scrollbar is needed
to see it. Scrolling to the right, i see content all the way: the top
image-buttons are far apart. A reload lays them out more compact, and the
scrollbar vanishes.

Comment 2

[David Pilcher]

This happens on W2k, 2002053104 too.

Comment 3

[Oddsson]

Confirming Comment #1 on 20020530 Win2k.

The real bug here is why is the refresh layout different from the first load
when the HTML is unchanged?

Comment 4

[Andrew Schultz]

Attachment: testcase

the image sizes are unspecified, so initial layout is ok.  however, the table
does not reflow after the images are retrieved and the sizes are known

Comment 5

[Andrew Schultz]

this is similar to what was mentioned in bug 97057 comment 6, although that bug
seems to be working now.

marking NEW
==> tables

Comment 6

[Andrew Schultz]

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

Comment 7

[Andrew Schultz]

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

Comment 8

[Andrew Schultz]

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

Comment 9

[Andrew Schultz]

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

Comment 10

[karnaze (gone)]

mass reassign to default owner

Comment 11

[Sven Krohlas]

I can still see this using Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7a)
Gecko/20040117

Comment 12

[hjp]

Another testcase, although the symptoms are slightly different:

http://www.hjp.at/tests/mozilla/table-layout-1.html

When you load the page, the first table is rendered incorrectly (third column
too wide), second (which differs only by added with and height parameters in an
img) is rendered correctly. 

When you visit another page and return with the back button, both tables are
correct.

When you reload the page, the first is rendered incorrectly again.

Comment 13

[Martijn Wargers (dead)]

Attachment: image for testcase

Comment 14

[Martijn Wargers (dead)]

Attachment: Another testcase

Well, the original testcase from the bug seems to work for me, using:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/2004-06-23
Firefox/0.8.0+
I can see the bug in the tescase from comment 12, but maybe this testcase is
also useful.

The first green table should always be short.
The second and third green table should always be long (the second one isn't
always in Mozilla)
The fourth green table should become long after the "fix last image" button is
pressed (doesn't happen in Mozilla)

Comment 15

[Martijn Wargers (dead)]

I think this is also (part of) the reason why:
http://www.fctwente.net/home_startpagina.php
is so messed up on first load/shift->reload.
The graphical results of the poll consists of a lot of 2px wide images without a
width set in the img tag. 
When I use adblock to block these images I get the broken layout consistently.

Comment 16

[Bernd]

Martin could you create a testcase with a layout break point (hyatts thing) for
the second table? Thanks.

Comment 17

[Martijn Wargers (dead)]

(In reply to comment #16)
> Martin could you create a testcase with a layout break point (hyatts thing) for
> the second table? Thanks.
I can do that, but that won't trigger the faulty behavior constantly. I can only
trigger the correct behavior 100% with Hyatt's hack, but not the incorrect
behavior. I guess there is some caching behavior going on with the image or
something.

That's why I made the 4th table in the testcase. When you press the button "fix
last image (should make green table long)" it makes the green table long in IE,
but not in Mozilla.

Comment 18

[Andrew Schultz]

the first testcase in this bug has worked fine since 1.8a1 (the URL now
specifies the image widths)

also, with Martin's testcase, the fourth table does grow when the button is
pressed, just not enough.  But it seems to be a different bug since the original
bug seems fixed.

Comment 19

[hjp]

I just tested Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817
against the test case in comment #12: Unfortunately, the behaviour is unchanged.
So this also seems to be a different bug than the one which was fixed in 1.8a1.

Comment 20

[Tomer Altman]

Testcase from comment #4 confirmed to still be buggy.
Using FF1.0PR: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913
Firefox/0.10

Comment 21

[Mats Palmgren (inactive)]

Bug occurs in Firefox 2006120701 on Linux
Bug does not occur in Firefox 2006120801 on Linux

-> FIXED (by the reflow branch landing)

Comment 22

[Martijn Wargers (dead)]

The Another testcase has become now less compatible with IE7, but it reacts now identical to Opera9. I guess what IE7 is doing is some odd quirk, that Mozilla should not try to mimick.