87418 - Table cell containing image w/ height unspecified grows on reload

Status: VERIFIED FIXED

(Core :: Layout: Tables, defect)

Description

[[e-mail]]

From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.5 i686)
BuildID:    20010618 

Load the URL http://overosa.dhs.org/musik.html. Observe the space between the
small menu table (musik (ladda hem) | licens...) at the bottom, and the table
above it -- it's about 10 pixels in height.
Now, reload the page, and the gap will widen, the menu table will drop down
about another 10 pixels.

Reproducible: Always
Steps to Reproduce:
1. Load http://overosa.dhs.org/musik.html
2. Reload the page

Actual Results:  The little menu table at the bottom is moved about ten pixels
down on the reload

Expected Results:  The little menu table should look the same at all times, as
there are no changing variables on that page

-

Comment 1

[Oliver Klee]

Over to HTML Tables.

Comment 2

[Tom Mraz]

Confirming Linux 2001070208
Also it's interesting that the background png of the menu is staying at its
previous (correct) position but it is clipped by the menu's box rectangle.

Comment 3

[[e-mail]]

Yes, I've noticed that problem also, with the background only displaying in
about half of the menu table.

Should part of this be moved over to ImageLib, or is it only related to HTML Tables?

Comment 4

[[e-mail]]

Still happening.

Is a better test case needed?

Comment 5

[[e-mail]]

mozBasic on irc://irc.mozilla.org/#mozillaZine helped me find out this is a
duplicate, of bug 82946.

Marking as such.

*** This bug has been marked as a duplicate of 82946 ***

Comment 6

[basic]

reporter: after looking at this bug again, I'm starting to think that it isn't a
dup of that bug. Could you download a more recent build to see if you still see
the bug in the latest build? I can't seem to verify the problem.

Comment 7

[[e-mail]]

It's still happening, but not just the same.

Another type of borkage!

On second reload, it now jumps up about 3-5 pixels.

Comment 8

[basic]

I'm thinking of reopening this bug as I'm beginning to think that it is not a
duplicate of the other bug. Could you try to create a simpler testcase (removing
what is not needed to reproduce the bug)? Thanks! Really fast response! How do
you do that? ;)

Comment 9

[[e-mail]]

Test cases are definitely not my forté -- I wouldn't be able to pin down the
problem. Someone else will have to do that.

Why I respond so quickly: I have no life :P

Comment 10

[basic]

Try removing stuff one by one from the page until the bug doesn't happen
anymore. When that happens, try to guess which ones causes the bug. Place them
back in and test again.

Comment 11

[Alfonso Martinez]

I'll attach a test case to prove that this is correctly dupped:

I was removing code from the page until almost all is left is a table with an
image WITHOUT specified height inside, an the problem still appears. 

If in the original code, the <img src="grafik/streck.png" width=435 alt="">
tag is replaced with one that has an specified height the problem doesn't appears.
if the src of the img is changed to a bigger one (as in the test case that I
will attach), then the text of the next cell is written over the image.

Comment 12

[Alfonso Martinez]

Attachment: Simplified test-case, with the image changed to a bigger one

Comment 13

[[e-mail]]

Okay.

But there's a difference -- in this case the image being displaced is the
_background_ image (which of course can't have its width and height specified).
Just making this clear... I am sure it is a dup. anyway.

Comment 14

[Alfonso Martinez]

No, read my previous comment. 
The image that creates the problem is precisely one of the few ones that is not
a background, it's the <img src="grafik/streck.png" width=435 alt="">
, which clearly isn't a background but an image without specified height.

The background images can be removed and the problem still exists.
Anyway, when 82946 is fixed maybe another problem appears (as the original that
you reported), if it happens then feel free to open this again. But after trying
to simplify the page provided what I found was 82946

Comment 15

[[e-mail]]

Okay, I see.

Comment 16

[[e-mail]]

This specific issue is happening, even though other bugs have had fixes for them.

Comment 17

[basic]

[e-mail] I don't see the bug anymore in build 2001082909 on win32
could you attach a screenshot?

The simplified test case works for me too, can you test?

Comment 18

[[e-mail]]

I can't reproduce the original test-case, but in the Simplified test-case, I can
see the a shift of about one or two pixels vertically after a reload.

Comment 19

[basic]

[e-mail] which build are you using?

Comment 20

[[e-mail]]

Oh, please excuse me for failing to mention that (I intended to...). An August
25th build... I'll try out a nightly now.

Yep, still happens with the simplified test case with current nightly, on
GNU/Linux. It jumps up a pixel after a reload.

Comment 21

[anthonyd]

in the attached testcase, the first cell shrinks vertically about 2-3 pixels 
after doing a reload (or a shift-reload).

on a related note, if i specify in the testcase the height of the image, this 
doesnt happen.  I will attach the modified testcase.

Comment 22

[anthonyd]

Attachment: new testcase

Comment 23

[karnaze (gone)]

mass reassign to default owner

Comment 24

[Daniel Wang]

testcases and url are worksforme (moz 2003032416/win98)
reporter (odd%findus.dhs.org), can you still reproduce the bug?

Comment 25

[[e-mail]]

No, this one is fixed. Verified in 1.3 and current nightly on GNU/Linux. Great.

Comment 26

[Daniel Wang]

reporter, FIXED is only for bug which has a fix specifically checked in.
The correct resolution is WORKSFORME.

but verifying anyway...