Closed Bug 812879 Opened 7 years ago Closed 7 years ago

Various things go wrong with page-break-inside: avoid (along with table, huge margins, float, overflow)


(Core :: Layout, defect, critical)

Not set



Tracking Status
firefox18 --- unaffected
firefox19 + fixed
firefox20 --- fixed
firefox-esr10 --- unaffected
firefox-esr17 --- unaffected


(Reporter: jruderman, Assigned: mats)


(Blocks 1 open bug)


(4 keywords, Whiteboard: [adv-main19-])

Crash Data


(4 files)

Attached file testcase
This testcase triggers:

ASSERTION: invalid col index: 'Error', file layout/tables/nsTableFrame.cpp
ASSERTION: column frames out of sync with cell map: 'Error', file layout/tables/BasicTableLayoutStrategy.cpp

A related testcase triggers:

ASSERTION: overflow list w/o frames: 'mFrames.NotEmpty()', file layout/generic/nsContainerFrame.cpp
Assertion failure: i < Length() (invalid array index),
Removing 'page-break-inside: avoid' from the test makes the assertions go away,
so it must be a regression from bug 685012.
Assignee: nobody → matspal
Keywords: regression
OS: Mac OS X → All
Hardware: x86_64 → All
Jesse, could you attach the related testcase too please?
Marking sec-high due to the array bounds assertion. Please adjust as appropriate.
Keywords: sec-high
Attached file testcase B
"testcase B" also crashes nightly: bp-fa867553-07e7-431c-ae31-933292121121
Crash Signature: [@ nsTableCellMap::Synchronize(nsTableFrame*) ]
Summary: Various things go wrong with table, huge margins, float, overflow → Various things go wrong with page-break-inside: avoid (along with table, huge margins, float, overflow)
The testcases reveals several bugs in the way nsTableFrame deals with row-group
continuations.  I've filed bug 815315 to address the underlying issues.  In this
bug I'll just remove the mistake that bug 685012 did to cause these edge cases
to occur.  The fault is in the block added for pushing floats for
'page-break-inside:avoid' here:
Flags: in-testsuite?
Attached patch fixSplinter Review
Don't try to push a float when the height is unconstrained.
Attachment #685904 - Flags: review?(fantasai.bugs)
Comment on attachment 685904 [details] [diff] [review]

We should never be incomplete if the the availableHeight is unconstrained, so maybe add an assertion that
  mContentArea.height == NS_UNCONSTRAINEDSIZE
are not both true?
Attachment #685904 - Flags: review?(fantasai.bugs) → review+
True, but we already do that in nsBlockFrame.cpp:1413 and it does assert
for both testcases here.  (Not sure why Jesse didn't mention it - perhaps
because we have other assertions involving UNCONSTRAINED sizes that safely
can be ignored.)
Comment on attachment 685904 [details] [diff] [review]

[Security approval request comment]
How easily can the security issue be deduced from the patch?
not at all

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?

Which older supported branches are affected by this flaw?

If not all supported branches, which bug introduced the flaw?
bug 685012

(FYI, the last two questions are ALWAYS redundant since other
fields in the bug already has that data)

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
same patch applies

How likely is this patch to cause regressions; how much testing does it need?
unlikely, the change makes this code block execute less often, so the
result is more like before the block was added by bug 685012
Attachment #685904 - Flags: sec-approval?
Attachment #685904 - Flags: sec-approval? → sec-approval+
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
Comment on attachment 685904 [details] [diff] [review]

See comment 12, low risk
Attachment #685904 - Flags: approval-mozilla-aurora?
Attachment #685904 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Whiteboard: [adv-main19-]
Group: core-security
Landed the crashtest:
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.