Closed
Bug 812879
Opened 12 years ago
Closed 12 years ago
Various things go wrong with page-break-inside: avoid (along with table, huge margins, float, overflow)
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
FIXED
mozilla20
Tracking | Status | |
---|---|---|
firefox18 | --- | unaffected |
firefox19 | + | fixed |
firefox20 | --- | fixed |
firefox-esr10 | --- | unaffected |
firefox-esr17 | --- | unaffected |
People
(Reporter: jruderman, Assigned: MatsPalmgren_bugz)
References
Details
(4 keywords, Whiteboard: [adv-main19-])
Crash Data
Attachments
(4 files)
266 bytes,
text/html
|
Details | |
723 bytes,
text/html
|
Details | |
2.23 KB,
patch
|
Details | Diff | Splinter Review | |
1.17 KB,
patch
|
fantasai.bugs
:
review+
akeybl
:
approval-mozilla-aurora+
abillings
:
sec-approval+
|
Details | Diff | Splinter Review |
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),
Assignee | ||
Comment 1•12 years ago
|
||
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
Blocks: page-break-inside
status-firefox18:
--- → unaffected
status-firefox19:
--- → affected
Keywords: regression
OS: Mac OS X → All
Hardware: x86_64 → All
Assignee | ||
Comment 2•12 years ago
|
||
Jesse, could you attach the related testcase too please?
Comment 3•12 years ago
|
||
Marking sec-high due to the array bounds assertion. Please adjust as appropriate.
Keywords: sec-high
Reporter | ||
Comment 4•12 years ago
|
||
Reporter | ||
Comment 5•12 years ago
|
||
"testcase B" also crashes nightly: bp-fa867553-07e7-431c-ae31-933292121121
Crash Signature: [@ nsTableCellMap::Synchronize(nsTableFrame*) ]
Reporter | ||
Updated•12 years ago
|
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)
Assignee | ||
Comment 6•12 years ago
|
||
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: https://bugzilla.mozilla.org/attachment.cgi?id=677034&action=diff#a/layout/generic/nsBlockReflowState.cpp_sec1
Assignee | ||
Comment 7•12 years ago
|
||
Updated•12 years ago
|
Flags: in-testsuite?
Assignee | ||
Comment 8•12 years ago
|
||
Don't try to push a float when the height is unconstrained.
Attachment #685904 -
Flags: review?(fantasai.bugs)
Assignee | ||
Comment 9•12 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=a6bd1c72a530
Comment 10•12 years ago
|
||
Comment on attachment 685904 [details] [diff] [review] fix We should never be incomplete if the the availableHeight is unconstrained, so maybe add an assertion that mContentArea.height == NS_UNCONSTRAINEDSIZE and !NS_FRAME_IS_FULLY_COMPLETE(reflowStatus) are not both true?
Attachment #685904 -
Flags: review?(fantasai.bugs) → review+
Assignee | ||
Comment 11•12 years ago
|
||
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.)
Assignee | ||
Comment 12•12 years ago
|
||
Comment on attachment 685904 [details] [diff] [review] fix [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? no Which older supported branches are affected by this flaw? Aurora 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?
Updated•12 years ago
|
Attachment #685904 -
Flags: sec-approval? → sec-approval+
Assignee | ||
Comment 13•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/9b169dfc8c38
Comment 14•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/9b169dfc8c38
Status: NEW → RESOLVED
Closed: 12 years ago
status-firefox20:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
Assignee | ||
Comment 15•12 years ago
|
||
Comment on attachment 685904 [details] [diff] [review] fix See comment 12, low risk
Attachment #685904 -
Flags: approval-mozilla-aurora?
Updated•12 years ago
|
status-firefox-esr10:
--- → unaffected
status-firefox-esr17:
--- → unaffected
Updated•12 years ago
|
tracking-firefox19:
--- → +
Updated•12 years ago
|
Attachment #685904 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Assignee | ||
Comment 16•12 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/19c3aa22d0ea
Updated•11 years ago
|
Whiteboard: [adv-main19-]
Updated•10 years ago
|
Group: core-security
Assignee | ||
Comment 17•10 years ago
|
||
Landed the crashtest: https://hg.mozilla.org/integration/mozilla-inbound/rev/6047dff1521c
Flags: in-testsuite? → in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•