225548 - Image with percentual width/height is displayed with incorrect size

Status: NEW

(Core :: Layout, defect)

Description

[Jonas Dygd]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031030
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031030

The height of the image that shows is incorrect. I have set the width and height
of the image to 100%. The image is positioned inside a table and the TD it's in
has a height of 100%

Reproducible: Always

Steps to Reproduce:
1. Go to the example URL
(http://www.novasoftware.se/WebViewer/design1.aspx?schoolid=001&code=1929394832)
2. Select a schedule in any of the top left combo boxes

Additional step:

1. Try changing just the width of the browser window (this affects the height of
the image, even when the elements above the image doesn't change their layout)


Actual Results:  
The schedule is shown as an image below, however it's height exceeds the window.
Netscape 7 does not have this problem.

Expected Results:  
Again, look at the page in Netscape 7. It displays the image correctly.

Comment 1

[Boris Zbarsky [:bzbarsky]]

I just looked with a 1.4-era build (equivalent to NS7) and the image is taller
than the page there too.

In fact, I see no reason the image would be shorter than the page -- all the
heights are unconstrained, so the natural image height is used.  Or does your
script do something to size the image?  If so, could you explain what it is?

Comment 2

[Mats Palmgren (inactive)]

The image is replaced with a new server side generated image as the window
is resized.  Try this:
1. load a schedule in a small window
2. select "View Image" in context menu

Repeat with in a bigger window -> it's a different (bigger) image.

The layout looks correct to me.

Comment 3

[Alex Hirzel]

Present with
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6b) Gecko/20031208

Comment 4

[Boris Zbarsky [:bzbarsky]]

Jonas, could you please explain exactly why you think this is a bug?  How is
your page determining the image size to send?

Comment 5

[Jonas Dygd]

(In reply to comment #4)
> Jonas, could you please explain exactly why you think this is a bug?  How is
> your page determining the image size to send?

Hmm... the fact that you're even asking this question should mean that the 
problem doesn't appear in your browser. 

I have now tried it with Mozilla Firefox and the bug appears there too.

If you go to the URL I listed above and select a schedule, then resize ONLY THE 
WIDTH of the browser window. This will not only affect the width of the image 
(which is set to 100%), but it will also affect the HEIGHT of the image, even 
though the image has it's height set to 100% and should adapt itself to the 
height of the browser window. 

I've experimented with this a bit, and found out that the width and height of 
the image are calculated to become exactly the same.. so it looks like Mozilla 
calculates the width right and then accidently uses the width value for the 
height as well.

It is clearly a bug to me. There is no reason that the height of an image 
element should be affected when the width of it's parent is changed.

Comment 6

[Jonas Dygd]

(In reply to comment #5)
> (In reply to comment #4)
> > Jonas, could you please explain exactly why you think this is a bug?  How is
> > your page determining the image size to send?

Sorry.. I forgot to answer your question. The page gets the width/height of the 
image element through script and reloads the picture. But this is really 
irrelevant here, because the problem appears BEFORE the image is reloaded. The 
source of the error is that Mozilla miscalculates the height of the image 
element in the first place (it may look like the 'natural' height of the image 
is being used, but that's because the image is reloaded using the height value 
(mis-)calculated by Mozilla)

Comment 7

[Jonas Dygd]

Attachment: An animated GIF image showing the problem

I've here made an animated GIF image displaying the bug. Notice that I'm
changing the width of the window, which affects both the width AND the height
of the image. The height should remain the same!

Comment 8

[Boris Zbarsky [:bzbarsky]]

David, do your image sizing changes affect this?

I can see the problem you're describing, Jonas.  It's hard to tell what's going
on without a smaller testcase.....

Comment 9

[Jonas Dygd]

(In reply to comment #8)
> David, do your image sizing changes affect this?
> I can see the problem you're describing, Jonas.  It's hard to tell what's 
going
> on without a smaller testcase.....

Alright! I have one right here (it seems like this problem only occours if the 
image is positioned inside a table):

<html>
<body>
<table style="WIDTH: 100%; HEIGHT: 100%" cellSpacing="0" cellPadding="0">
<tr>
<td>
<img width="100%" height="100%">
</td>
</tr>
</table>
</body>
</html>

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: The testcase

I don't see the height changing in this testcase....

Comment 11

[Jonas Dygd]

Attachment: Small test case

I changed the picture to a bigger one (exceeding the browser window's
proportions) and now the bug will show. In this case though, the width does not
equal the height. Try commentating out the table tags (leaving only the img
tag) and you should see the behaviour I would expect this code to have.

Comment 12

[Alan Batie]

I think a problem I just noticed is related: I have a div to make a background
image in a frame.  I use width=100% and height=100% so the image will stretch to
fill the browser; it's in a div because there's a logo image I want to float in
the center over it (which was really fun to get to work in different browsers!).
 Anyway, this used to work in earlier mozillas, and has stopped working in 1.6:
http://www.triangleproductions.org/14th-season/index.html.  It's scaling with
the width of the browser, but it's scaling proportionally as though it were
keeping the aspect ratio intact, which would be fine if I had only used one of
width or height, but I used both to override that.

<div id=curtains
  style="position:absolute; top:0; left:0; z-index:0; height=100%;">

  <img src="images/curtains-closed-8x4.jpg" width=100% height=100%>
</div>

Comment 13

[Mats Palmgren (inactive)]

Attachment: Testcase #2

Comment 14

[Mats Palmgren (inactive)]

Confirming bug, 2004-02-20-08 trunk Linux.

It only occurs on the initial reflow - a reload resizes the image correctly.
It only occurs in Quirks mode.
It seems to only occur when using a table as the container.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Bernd, any idea what's up?

Comment 16

[Bernd]

Attachment: reflow log

We I believe we reflow the image with the computed width of 600px and is does
not the image intrinsic size it assumes to use width also as the height. I
believe  ( id didnt debug)
http://lxr.mozilla.org/mozilla/source/layout/html/base/src/nsImageFrame.cpp#789
or something similiar to it seems to be the source of that issue. (its a dupe I
know that I looked at that line before)

Comment 17

[Bernd]

probably I had bug 191389 in mind

Comment 18

[Jonas Dygd]

Any news on this bug? I've managed to make an ugly workaround for my program, 
but it would be nice to see have solved in future Mozilla versions.

Comment 19

[Mats Palmgren (inactive)]

Testcase #2 seems to work fine in SeaMonkey 2006120701 (pre reflow branch),
but not in SeaMonkey 2006120801 (post), both on Linux.
The 2006120701 rendering is the same as in IE7, Opera9 and Webkit.
Not sure which is correct per CSS 2.1, marking regression of 300030 for now.

Comment 20

[Boris Zbarsky [:bzbarsky]]

> Not sure which is correct per CSS 2.1

Testcase is in quirks mode anyway...

Comment 21

[Mats Palmgren (inactive)]

Attachment: Testcase #2b (Standards mode)

Standards mode version of Testcase #2.  Pre/post-reflow branch render this
testcase the same.

Comment 22

[Bernd]

Quirks mode + pct height wrong = special height reflow

in standards mode the pct height becomes auto.

Comment 23

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

Plussing for the regression in comment #19

Comment 24

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

I think we probably want to get a separate bug filed for that regression, actually, and transfer the blocking1.9+ to it.  dholbert might be able to look at that...

Comment 25

[Daniel Holbert [:dholbert]]

I've actually already got a separate bug for the regression: bug 385823

Can we transfer the blocking1.9+ to that one?

Comment 26

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

blocking1.9+ and reflow branch dependency transferred to bug 385823.