438588 - "max-width: 100%" on image makes [spec-width table > overflow:hidden div > img] too wide

Status: RESOLVED DUPLICATE of bug 434230

(Core :: Layout, defect)

Description

[Niclas]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9) Gecko/2008052906 Firefox/3.0

Instead of being wided so that the right end of the page is visible it is wided so that you have to scroll to see all of the content. Seem to happen if there is large pictures involved.

Reproducible: Always

Steps to Reproduce:
1.Go in to: http://www.sweclockers.com/forum/showthread.php?s=b8a44033d51e762b2f753d1a90cd3d49&threadid=775945
2.Check how it looks.
3.Check with another web browser, like IE.
4.There you go.
Actual Results:  
The page got much wider than it was suppose to.

Expected Results:  
The software should have resized the pictures so that it would fit within the screen without having to scroll to the right.

Used the standard theme that comes with Firefox 3. 

Extensions: 
Adblock Plus 0.7.5.4
Download Statusbar 0.9.6.1
DownloadHelper 3.0.4
Forecastfox 0.9.7.6
Quicknote 0.6.0.4
QuickRestart 1.1.2
WOT 20080519

Comment 1

[Ria Klaassen (not reading all bugmail)]

This is a regression from Bug 402567. Probably a duplicate of Bug 409736.

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to comment #1)
> Probably a duplicate of Bug 409736.

Similar, but not a duplicate.  We match WebKit completely on that bug, but we don't on this bug.

The page is wide because of the huge images embedded in comments, which are wrapped with <div class="vbimage">, which have overflow:hidden.

I'm guessing that WebKit and old-Firefox would ignore the width of images inside of scrollframes, and the images would end up resizing to match the eventual scrollframe width.  But in current Firefox 3, the image's min-width gets passed through, and so the scrollframe is as large as the image.

Or something like that.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: image for use in testcase

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

FF2 and WebKit show "Expected Behavior" on this testcase.

FF3 and IE7 show unexpected behavior (image is wider than orange bar.)


I think the original URL may use some sort of hack to get around this bug's issue in IE.  When I load the URL in FF2 / WebKit, the images resize as I make the window skinnier or wider, but when I load it in IE, the images are fixed at an intermediate size.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to comment #4)
> I think the original URL may use some sort of hack to get around this bug's
> issue in IE.

(though it's not via user-agent-sniffing -- if I spoof IE7's user agent from FF3, it doesn't change the FF3 behavior.)

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: reference 1

This reference case looks correct in firefox 3.  All I changed was:

testcase:    img             { max-width: 100% }
reference:   img             { width: 100% }

(Interestingly, IE7 is broken on this reference case. It renders it the same as it & FF3 render the testcase)

Comment 7

[Daniel Holbert [:dholbert]]

Requesting wanted1.9.0.x, because:
 - This is a layout regression in Firefox 3
 - Our behavior here doesn't really make sense, AFAIK -- it's pretty broken that we allocate more width for a "max-width: 100%" element than for a "width: 100%" element.

Comment 10

[Daniel Holbert [:dholbert]]

This bug is not a dupe -- please see comment 2 and my comments since then.

Comment 11

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

Sorry, I didn't read comment 2 (and sorry for previous error with duplicating).

Anyway IMO Firefox behaviour is correct and this is just a duplicate of bug 409736. The cell width with table-layout:auto is the width of its content, and an image is not different from text or any other content. If WebKit doesn't add space occupied by image, it wrongs.

Comment 12

[Daniel Holbert [:dholbert]]

(In reply to comment #11)
> Sorry, I didn't read comment 2 (and sorry for previous error with duplicating).
> 
> Anyway IMO Firefox behaviour is correct and this is just a duplicate of bug
> 409736. 

Erm, no ... the bug as described in the comments since comment 2 is quite different from bug 409736.  See the testcase and reference case I attached, which AFAIK should match.

As stated in Comment 7, the bug is basically this: it seems quite wrong that we'd cap the image's size when "width" is specified, but not cap it when "max-width" is specified.  That's the bug here, IMHO.  (though I admittedly haven't worked with max-width very much, so I could be wrong)

Comment 13

[philippe (part-time)]

Is bug 434230 any different from this one ?

Comment 14

[Daniel Holbert [:dholbert]]

Yeah, I think they're the same.  Duping this bug to that one, as this bug is more cluttered and was filed later.