Open
Bug 681499
Opened 13 years ago
Updated 2 years ago
A floated image with a percentage height and auto-height parent in quirks mode is not placed at the right horizontal position
Categories
(Core :: Layout: Floats, defect)
Tracking
()
NEW
People
(Reporter: mail, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: regression, testcase)
Attachments
(3 files)
big image
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20100101 Firefox/6.0
Build ID: 20110811165603
Steps to reproduce:
Open a website with a big image,
for example open the following URL:
http://www.seidl-e.de/wk/gpic.shtml?num=2&flg=0
(Contains 5 MPix image)
Actual results:
Image disappears, because it is upscaled instead of downscaled.
(You will see it when zooming down to lowest scale.)
Expected results:
Image should have been rescaled to fill window height.
Command:
<img src="2.jpg" align="right" height="100%" hspace="0" alt="Bild: Blick vom Watt aus">
Should rescale image from 2.560px × 1.920px to about 623px × 467px,
does rescale to 2.801px × 2.101px (makes it bigger!).
(Previous versions (dont know until which) did it right.)
(Microsoft IE 8 does it right.)
|
||
Comment 1•13 years ago
|
||
the testcase doesn't load for me
Mozilla/5.0 (Windows NT 5.1; rv:8.0a1) Gecko/20110813 Firefox/8.0a1
http://www.seidl-e.de/wk/gpic.shtml?num=2&flg=0
Confirming
> the testcase doesn't load for me
I assume that's the bug? Zoom out!
|
|
||
Comment 3•13 years ago
|
||
>I assume that's the bug? Zoom out!
of course not. Doesn't load != doesn't see anything
I found the reason: there is something wrong with IPV6 on that server
confirming with Seamonkey trunk on win32
Status: UNCONFIRMED → NEW
Component: General → Layout
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → layout
Version: 6 Branch → Trunk
This is quirksmode only
Reporter:
Your site is in quirksmode, thats bad. You should use a standards mode triggering doctype, e.g. just <!DOCTYPE html>
To get the 100% thing working in standards mode, you need to add styling like this:
<style>
html { height: 100% }
body { height: 95% }
</style>
Keywords: regression,
testcase
Summary: Downscaling fault with big images → Downscaling fault with big images in quirksmode
|
||
Comment 7•13 years ago
|
||
What's happening here is that the floated image is sized correctly but positioned way off the left side of the page. In particular, for my small window testcase I see it ending up 488px wide by 366px tall but placed 1958px off the left side of the viewport. In my case the viewport is 610px wide. 1958+610 = 2568. The body has an 8px right margin and the image's intrinsic width is 2560px, so we're placing the image's left edge so that its right edge will line up with the right edge of the body if the image has its intrinsic width. But then it ends up with a much smaller width, of course.
Oddly, giving the body a 100% height fixes the problem....
Component: Layout → Layout: Floats
QA Contact: layout → layout.floats
Summary: Downscaling fault with big images in quirksmode → A floated image with a percentage height and auto-height parent in quirks mode is not placed at the right horizontal position
|
|
||
Comment 8•13 years ago
|
||
This regressed between fx3.6 and fx4.
|
|
||
Comment 9•13 years ago
|
||
This issue seems to be that FloatMarginWidth() uses the computed height of the block as the containing block height to pass to ComputeSize(). And the computed height in this case is auto, so we end up with the intrinsic height in this case. And then we do this:
floatX = floatAvailableSpace.mRect.XMost() - floatMarginWidth;
and lose.
Ideally, we'd pass the correct containing block height (the same one that reflow will use) to FloatMarginWidth...
I assume this is a regression from dbaron's float changes in fx4?
|
|
||
Comment 10•13 years ago
|
||
Regression winodw(cached m-c hourly)
Works:
http://hg.mozilla.org/mozilla-central/rev/373d1b393f28
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100805 Minefield/4.0b4pre ID:20100805200154
Fails:
http://hg.mozilla.org/mozilla-central/rev/8ab7ef79b673
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100805 Minefield/4.0b4pre ID:20100805224228
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=373d1b393f28&tochange=8ab7ef79b673
Suspected bug:
Bug 563584 - ###!!! ASSERTION: float manager state should match saved state
|
|
||
Comment 11•13 years ago
|
||
Incidentally this will also cause problems when we have anonymous blocks wrapping inlines if the float is reflowed by the anonymous block, since the anonymous block will NOT be the containing block.
|
|
||
Comment 12•13 years ago
|
||
And in fact it's already a problem when the containing block is not the block frame; e.g. table cells. Standards-mode testcase showing that coming up.
Blocks: 563584
|
|
||
Comment 13•13 years ago
|
||
(In reply to Boris Zbarsky (:bz) from comment #9)
> This issue seems to be that FloatMarginWidth() uses the computed height of
> the block as the containing block height to pass to ComputeSize(). And the
> computed height in this case is auto, so we end up with the intrinsic height
> in this case. And then we do this:
>
> floatX = floatAvailableSpace.mRect.XMost() - floatMarginWidth;
>
> and lose.
Sorry, how did you get from heights to widths here?
|
|
||
Comment 15•13 years ago
|
||
Oh, the point is that floatMarginWidth is set to the width returned by ComputeSize() on the float (plus margin/padding/border). And for an image the width returned by ComputeSize() depends on the height of the image if the computed width is auto. And in this case the height the image actually ends up with and the height that's used to detemined the width returned from FloatMarginWidth() are different, because the image has a percentage height and different containing block heights are used for the two computations.
|
Reporter | |
Comment 16•13 years ago
|
||
Well that looks fine, You are after it.
Thanks for Your work, folks!
|
||
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•