466395 - misalignment of inline-blocks with fixed height and content overflowing at least 547px

Status: VERIFIED FIXED

(Core :: Layout: Block and Inline, defect)

Description

[Wladimir Palant]

Attachment: Testcase

The testcase has an inline block like this:

<div style="display: inline-block; height: 100%;">
   much text
</div>

As soon as the text inside this block exceeds a certain height (maybe twice the window size?) this block is positioned in such a way that its bottom edge is where its top edge should be. This does not happen if the text inside the block doesn't reach "critical mass", and it also doesn't happen if the block is preceded by another inline block (or an image). And, of course, this doesn't happen in either Internet Explorer or Opera.

An Adblock Plus user noticed that issue on http://macbay.de/ - on this site #wrapper is the problematic block, and it only shows up correctly because it follows an image. If that image fails to load (for example because it was blocked by Adblock Plus) this bug strikes and makes the entire page unusable.

Reproduced in Firefox 3.0.4 and Minefield build 20081120.

Comment 1

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

I bet nsLineLayout::VerticalAlignFrames is getting confused by a box having a baseline that's so far outside of itself because we're going above VERTICAL_ALIGN_FRAMES_NO_MINIMUM.  (The baseline is the position of the last line.)

Comment 2

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

Attachment: patch

Just as I thought.

The bug turns out to be quirks-mode only.  I added one test in quirks mode (fails without patch, passes with) and one in standards mode (passes with or without patch).

Comment 3

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

Note that the condition required to cause the bug is that you need an inline-block whose content overflows it such that the baseline of the last line of the inline block is at least 547px (== 2^15 appunits) below the bottom of the inline-block.

Comment 4

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

Comment on attachment 349681 [details] [diff] [review]
patch

Very simple patch to fix a rather nasty bug (or at least postpone it to *much* larger sizes).

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 349681 [details] [diff] [review]
patch

a191=beltzner

Comment 6

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

Attachment: mq-formatted patch with From: header

Comment 7

[Shawn Wilsher :sdwilsh]

http://hg.mozilla.org/mozilla-central/rev/11f15643c403

Comment 8

[Wladimir Palant]

Given that this affects real-world sites that are broken without being aware of it - should this land on 1.9.0 branch as well? The patch is very simple and I don't see any risk there.

Comment 9

[Aakash Desai [:aakashd]]

1.9.1
reftests: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/2a0beb6161ed
pushed: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/11f15643c403


trunk:
reftests: http://hg.mozilla.org/mozilla-central/rev/b7d995725e14

verified FIXED on builds: 
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090505 Minefield/3.6a1pre ID:20090505030940

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090505 Shiretoko/3.5b5pre ID:20090505030932