522604 - Fixed-width div containing two floated divs prints missing one div

Status: RESOLVED WORKSFORME

(Core :: Printing: Output, defect)

Description

[Chris Lawson (gone)]

Attachment: minimal testcase

Spun off from bug 255399, the attached testcase (still) doesn't print properly on trunk (missing the right-hand yellow-outlined box).

STR:

1) Open testcase in trunk (Gecko 1.9.3pre) build.
2) Print, or print to PDF (in OS X, at least, though I assume this would work equally well in any OS with appropriate print drivers).

Expected results: page prints as seen on screen.

Actual results: red-outlined column is (mostly) missing from output.

Some observations from making the testcase:

  * If the right-hand box (box B) is taller than the left-hand box (box A), the extra height appears immediately below box A. This suggests the right-hand box might be in the print output but positioned incorrectly, probably "behind" box A.

  * The header always shows up all by itself on page 1 of the original testcase (attachment 155946 [details]). This is due to the clear:both declaration, and I'm not sure whether that might be another bug or not (seems likely, since it's unexpected that print output would differ from screen output in that case). Removing the clear:both, which I've done in this testcase, doesn't affect the missing-ness of box B.

  * It doesn't matter whether box B is floated right or left. I tried both, but this testcase has it floated on the right.

  * Putting a border-bottom of X pixels on the contentarea div will allow X pixels of box B to appear at the bottom of page 1 and will force a corresponding number of pixels of box A onto page 2. Oddly enough, the "bottom" border appears at what looks like the top of the div. (Seems like a div ought to encompass the height of its enclosed elements, whether they're floating or not, but I don't know the spec that well. Let me know if this should be a separate bug or is already filed.)

  * For a fixed-width div of width X, the width of the two floated divs plus any borders needs to be greater than X-1 pixels.

Comment 1

[philippe (part-time)]

Attachment: minimal testcase

attachment 406591 [details] has a small box-model mistake - the right red-bordered column dropped below the left one on screen. :-).

Comment 2

[Chris Lawson (gone)]

Actually, that's semi-intentional -- the bug shows up in trunk either way -- but yeah, I uploaded the wrong one.

Comment 3

[philippe (part-time)]

(In reply to comment #0)

> Oddly enough, the "bottom"
> border appears at what looks like the top of the div. (Seems like a div ought
> to encompass the height of its enclosed elements, whether they're floating or
> not, but I don't know the spec that well. Let me know if this should be a
> separate bug or is already filed.)

No, that is normal. The #contentarea is technically empty as it contains only floated blocks (floats are removed from the flow).

Comment 4

[philippe (part-time)]

observation:
On Gecko 1.9.0.x, the red bordered box is fully visible below the blue box on the print output. With Gecko 1.9.1 and trunk, the red bordered box is behind the bleu box in the printed output. This changed between the 20090104 and 20090105 build:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9f497b1505d2&tochange=c04e27e056ba
That is bug 191448.

Comment 5

[Chris Lawson (gone)]

(In reply to comment #4)
> observation:
> On Gecko 1.9.0.x, the red bordered box is fully visible below the blue box on
> the print output. With Gecko 1.9.1 and trunk, the red bordered box is behind
> the bleu box in the printed output.

That sounds like a regression, then. I see the same results with 1.9.0.x that you do.

Comment 6

[James Napolitano]

Bug 220102 may be related to this bug, though that one dates back to Gecko 1.5, long before when this bug was reportedly caused.

Comment 7

[James Napolitano]

Both testcases now work (the red box is visible in print preview) in Firefox 4b11 (tested on WinXP). FTR, the bug was still present in Firefox 3.6 (tested on Linux). According to bz in bug 220102 comment 11, "float printing was substantially reworked in Gecko 2.0", so this bug must have been fixed as part of those changes.