STR: Print-preview attached testcase. Look at second page. ACTUAL RESULTS: "text after table" is placed too high -- it overlaps the orange bottom-border of the table. EXPECTED RESULTS: "text after table" should be placed after the orange bottom-border. NOTES: * This only happens on the second page (and later pages, presumably). If you shrink the table-height so it all fits on one page, the bug goes away. * If you increase the border-width to be much larger, you'll hit a related bug with text & borders overlapping (bug 484256), even outside of print-preview. *That* bug is not a regression, however, whereas *this* bug here (using smaller borders) *is* a regression in mozilla-central WRT 1.9.1. * If I compare a 1.9.1 print-preview rendering to a mozilla-central print-preview rendering, it looks like they place the border in the same place -- the difference is specifically in the placement of the "text after table". (mozilla-central places the text higher up on the page.) BROKEN: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090318 Minefield/3.6a1pre WORKING: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b4pre) Gecko/20090319 Shiretoko/3.5b4pre

Possibly related to bug 484258, which is also a regression wrt 1.9.1 relating to borders & border-collapse:collapse. However, in that bug, the *borders* have changed placement in mozilla-central; whereas, in this bug, the borders are still placed the same, and it's the *text* whose placement has changed.

This seems to have improved a bit.

I got this regression range however, the bug varied with window size. If maximized, the bug always appeared. If not maximized, "text after table" did not always overlap the orange (but usually did). Regression window: works: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090208 Minefield/3.2a1pre http://hg.mozilla.org/mozilla-central/rev/688c44602a55 broken: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090209 Minefield/3.2a1pre http://hg.mozilla.org/mozilla-central/rev/0ebeefbbdac0 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=688c44602a55&tochange=0ebeefbbdac0

Thanks Matt! Looks like a regression (or at least a behavior-change) from bug 155955, then. FWIW, it looks like the behavior has changed in both mozilla-central and in 1.9.2 branch since I filed this bug. Using print-preview to test, here's my current results across 1.9.1/1.9.2/m-c: - In a Firefox 3.5.7 build[1], I see two orange borders: one at the bottom of the first page, and one on the second page just above "text after table". - In today's 1.9.2 nightly[2], I only get an orange border at the bottom of the first page. Also, "text after table" is placed slightly higher than in 1.9.1. - In today's m-c nightly[3], I get no orange on either page. "text after table" is placed the same as in 1.9.2. Note that in none of those cases did I get text overlapping an orange border (the original "actual results" reported in comment 0). Perhaps there was another checkin after this bug was filed, which stopped us from drawing the border on the second page? [1] Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 [2] Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.2pre) Gecko/20100207 Namoroka/3.6.2pre [3] Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a2pre) Gecko/20100207 Minefield/3.7a2pre

(In reply to comment #4) > - In today's m-c nightly[3], I get no orange on either page. This lack-of-any-orange is a new regression in mozilla-central w.r.t. 1.9.2, and it probably needs a new bug.

Here are the other windows for all changes in the testcase on trunk (as I see it). Do you need the windows on each branch as well? Other regression windows: Part 2: broken - orange page 1-2 overlap: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091104 Minefield/3.7a1pre http://hg.mozilla.org/mozilla-central/rev/41c421f97869 broken - orange page 2 overlap: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091105 Minefield/3.7a1pre http://hg.mozilla.org/mozilla-central/rev/91e00d39570f http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=41c421f97869&tochange=91e00d39570f Part 3: broken - orange page 2 overlap: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091212 Minefield/3.7a1pre http://hg.mozilla.org/mozilla-central/rev/d379a17cbf8f broken - no orange: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091213 Minefield/3.7a1pre http://hg.mozilla.org/mozilla-central/rev/3ff17b03644e http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d379a17cbf8f&tochange=3ff17b03644e

Dates are the date of the nightly on trunk.

(In reply to comment #6) > Here are the other windows for all changes in the testcase on trunk (as I see > it). Do you need the windows on each branch as well? Thanks! Ranges on trunk are sufficient -- no need to do branches. > Part 2: > ... > http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=41c421f97869&tochange=91e00d39570f That looks like Bug 452319. > Part 3: > ... > http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d379a17cbf8f&tochange=3ff17b03644e And that looks like bug Bug 530686 or Bug 531461 (which were pushed together). I don't think either of those behavior-changes (Part 2 or Part 3) were intended outcomes of those bug's patches.

I never saw the bug you saw on 1.9.2 on m-c so I tracked it down on 1.9.2. Another regression window: Part 4 - appears unique on 1.9.2: broken - orange on page 1-2 overlaps text: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2b6pre) Gecko/20091212 Namoroka/3.6b6pre http://hg.mozilla.org/releases/mozilla-1.9.2/rev/101b2f5eef9a broken - orange only on page 1: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2b6pre) Gecko/20091213 Namoroka/3.6b6pre http://hg.mozilla.org/releases/mozilla-1.9.2/rev/5e9329cfac70 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=101b2f5eef9a&tochange=5e9329cfac70

Testcase images for all versions of firefox mentioned in this bug so far. Regressions (changes) are clearly marked.

>related bug with text & borders overlapping (bug 484256) sorry but that bug is not related, at least the fix for bug 484256 does not change the behavior of this bug.

This still does not work.