Bug 1308876 - Avoid initiating special-height reflow as a result of new paginated non-dirty reflows. r=dholbert
Previously, in paginated mode, all reflows were dirty reflows, since
tables do not split outside of printing, and prior to the primary patch
in bug 1308876, all reflows during printing are dirty reflows. (The
isPaginated test here is actually for real pages, not fragmentation in
general. However, the use here is appropriate for the meaning of
whether it's possible for the table to fragment.)
The fact that all reflows were dirty reflows meant that the
NS_FRAME_CONTAINS_RELATIVE_BSIZE flag was always cleared immediately
before reflow in ReflowInput::InitResizeFlags (which might also have set
the flag on *ancestors*). This meant that, prior to the primary patch
in bug 1308876, the initial value of needToInitiateSpecialReflow that
was initialized from the presence of the
NS_FRAME_CONTAINS_RELATIVE_BSIZE flag was always false. This patch
preserves that initialization in the presence of the change in the
primary patch in bug 1308876.
This caused a failure in a single test in our test suite, and in a
rather complicated way. The test was
layout/base/crashtests/470851-1.xhtml, in which there was both a
difference in assertion count (due to the bogus assertion "data loss -
incomplete row needed more height than available, on top of page" in
nsTableRowGroupFrame::SplitRowGroup, whose companion assertion "data
loss - complete row needed more height than available, on top of page"
is already just an NS_WARNING) that caused a test failure, and a
difference in layout (the test split across 3 pages rather than 2) that
did not cause a test failure.
This patch fixes the difference in layout. The immediate cause of the
layout difference was that a cell (the second outermost) on the second
page had a height, computed in CalcUnpaginatedBSize, that was large
enough to cause it to need to continue onto the third page. This height
came (via nsTableRowFrame::GetUnpaginatedBSize) from the
UnpaginatedHeightProperty stored on the first-in-flow of its row, on the
first page, stored by CacheRowBSizesForPrinting called in
nsTableRowGroupFrame::ReflowChildren during the reflow of its row group
on the first page, in a special height reflow initiated during the
second-pass constrained-height reflow of the table (still,
second-outermost) on the first page, due to the change being fixed in
this patch.
MozReview-Commit-ID: 3E84VwdXuPs
2017-07-13 05:37:12 +03:00
|
|
|
<!DOCTYPE HTML>
|
2017-07-27 08:53:46 +03:00
|
|
|
<html class="reftest-paged">
|
Bug 1308876 - Avoid initiating special-height reflow as a result of new paginated non-dirty reflows. r=dholbert
Previously, in paginated mode, all reflows were dirty reflows, since
tables do not split outside of printing, and prior to the primary patch
in bug 1308876, all reflows during printing are dirty reflows. (The
isPaginated test here is actually for real pages, not fragmentation in
general. However, the use here is appropriate for the meaning of
whether it's possible for the table to fragment.)
The fact that all reflows were dirty reflows meant that the
NS_FRAME_CONTAINS_RELATIVE_BSIZE flag was always cleared immediately
before reflow in ReflowInput::InitResizeFlags (which might also have set
the flag on *ancestors*). This meant that, prior to the primary patch
in bug 1308876, the initial value of needToInitiateSpecialReflow that
was initialized from the presence of the
NS_FRAME_CONTAINS_RELATIVE_BSIZE flag was always false. This patch
preserves that initialization in the presence of the change in the
primary patch in bug 1308876.
This caused a failure in a single test in our test suite, and in a
rather complicated way. The test was
layout/base/crashtests/470851-1.xhtml, in which there was both a
difference in assertion count (due to the bogus assertion "data loss -
incomplete row needed more height than available, on top of page" in
nsTableRowGroupFrame::SplitRowGroup, whose companion assertion "data
loss - complete row needed more height than available, on top of page"
is already just an NS_WARNING) that caused a test failure, and a
difference in layout (the test split across 3 pages rather than 2) that
did not cause a test failure.
This patch fixes the difference in layout. The immediate cause of the
layout difference was that a cell (the second outermost) on the second
page had a height, computed in CalcUnpaginatedBSize, that was large
enough to cause it to need to continue onto the third page. This height
came (via nsTableRowFrame::GetUnpaginatedBSize) from the
UnpaginatedHeightProperty stored on the first-in-flow of its row, on the
first page, stored by CacheRowBSizesForPrinting called in
nsTableRowGroupFrame::ReflowChildren during the reflow of its row group
on the first page, in a special height reflow initiated during the
second-pass constrained-height reflow of the table (still,
second-outermost) on the first page, due to the change being fixed in
this patch.
MozReview-Commit-ID: 3E84VwdXuPs
2017-07-13 05:37:12 +03:00
|
|
|
<!--
|
|
|
|
|
This reference matches our current rendering, which isn't necessarily
|
|
|
|
|
correct, but I'd at least like to know about it if it changes, given how
|
|
|
|
|
little test coverage of this we currently have.
|
|
|
|
|
-->
|
|
|
|
|
<style>
|
|
|
|
|
html, body { margin: 0; padding: 0; }
|
|
|
|
|
</style>
|
Bug 1322780 - Part 2: Support unprefixed min-content and max-content. r=mats,emilio
Support unprefixed min-content and max-content and treat the prefixed
version as aliases for
1. width, min-width, max-width if inline-axis is horizontal, and
2. height, min-height, max-height if inline-axis is vertical, and
3. inline-size, min-inline-size, max-inline-size, and
4. flex-basis.
Besides, update the test cases to use unprefixed max-content and
min-content.
Depends on D7535
Differential Revision: https://phabricator.services.mozilla.com/D7536
--HG--
extra : moz-landing-system : lando
2018-12-18 21:47:37 +03:00
|
|
|
<div id="page1" style="border: 2px solid black; background: yellow; height: 2in; box-sizing: border-box; padding: 3px; width: min-content">
|
2020-05-18 03:47:05 +03:00
|
|
|
<div style="background: orange; height: calc(2in - 15px); padding: 3px;">
|
Bug 1308876 - Avoid initiating special-height reflow as a result of new paginated non-dirty reflows. r=dholbert
Previously, in paginated mode, all reflows were dirty reflows, since
tables do not split outside of printing, and prior to the primary patch
in bug 1308876, all reflows during printing are dirty reflows. (The
isPaginated test here is actually for real pages, not fragmentation in
general. However, the use here is appropriate for the meaning of
whether it's possible for the table to fragment.)
The fact that all reflows were dirty reflows meant that the
NS_FRAME_CONTAINS_RELATIVE_BSIZE flag was always cleared immediately
before reflow in ReflowInput::InitResizeFlags (which might also have set
the flag on *ancestors*). This meant that, prior to the primary patch
in bug 1308876, the initial value of needToInitiateSpecialReflow that
was initialized from the presence of the
NS_FRAME_CONTAINS_RELATIVE_BSIZE flag was always false. This patch
preserves that initialization in the presence of the change in the
primary patch in bug 1308876.
This caused a failure in a single test in our test suite, and in a
rather complicated way. The test was
layout/base/crashtests/470851-1.xhtml, in which there was both a
difference in assertion count (due to the bogus assertion "data loss -
incomplete row needed more height than available, on top of page" in
nsTableRowGroupFrame::SplitRowGroup, whose companion assertion "data
loss - complete row needed more height than available, on top of page"
is already just an NS_WARNING) that caused a test failure, and a
difference in layout (the test split across 3 pages rather than 2) that
did not cause a test failure.
This patch fixes the difference in layout. The immediate cause of the
layout difference was that a cell (the second outermost) on the second
page had a height, computed in CalcUnpaginatedBSize, that was large
enough to cause it to need to continue onto the third page. This height
came (via nsTableRowFrame::GetUnpaginatedBSize) from the
UnpaginatedHeightProperty stored on the first-in-flow of its row, on the
first page, stored by CacheRowBSizesForPrinting called in
nsTableRowGroupFrame::ReflowChildren during the reflow of its row group
on the first page, in a special height reflow initiated during the
second-pass constrained-height reflow of the table (still,
second-outermost) on the first page, due to the change being fixed in
this patch.
MozReview-Commit-ID: 3E84VwdXuPs
2017-07-13 05:37:12 +03:00
|
|
|
<div style="background: brown; color: black;padding: 1px;">A</div>
|
|
|
|
|
</div>
|
|
|
|
|
</div>
|
2020-05-18 03:47:05 +03:00
|
|
|
<div id="page2" style="border: 2px solid black; background: yellow; height: 2in; box-sizing: border-box; padding: 2px 3px 3px 3px; border-bottom: none; padding-bottom: 0; width: min-content">
|
|
|
|
|
<div style="background: orange; height: calc(2in - 6px); padding: 2px 3px 0 3px">
|
|
|
|
|
<div style="border: 1px solid fuchsia; background: aqua; height: calc(2in - 7px); border-bottom: none; color: transparent">A</div>
|
Bug 1308876 - Avoid initiating special-height reflow as a result of new paginated non-dirty reflows. r=dholbert
Previously, in paginated mode, all reflows were dirty reflows, since
tables do not split outside of printing, and prior to the primary patch
in bug 1308876, all reflows during printing are dirty reflows. (The
isPaginated test here is actually for real pages, not fragmentation in
general. However, the use here is appropriate for the meaning of
whether it's possible for the table to fragment.)
The fact that all reflows were dirty reflows meant that the
NS_FRAME_CONTAINS_RELATIVE_BSIZE flag was always cleared immediately
before reflow in ReflowInput::InitResizeFlags (which might also have set
the flag on *ancestors*). This meant that, prior to the primary patch
in bug 1308876, the initial value of needToInitiateSpecialReflow that
was initialized from the presence of the
NS_FRAME_CONTAINS_RELATIVE_BSIZE flag was always false. This patch
preserves that initialization in the presence of the change in the
primary patch in bug 1308876.
This caused a failure in a single test in our test suite, and in a
rather complicated way. The test was
layout/base/crashtests/470851-1.xhtml, in which there was both a
difference in assertion count (due to the bogus assertion "data loss -
incomplete row needed more height than available, on top of page" in
nsTableRowGroupFrame::SplitRowGroup, whose companion assertion "data
loss - complete row needed more height than available, on top of page"
is already just an NS_WARNING) that caused a test failure, and a
difference in layout (the test split across 3 pages rather than 2) that
did not cause a test failure.
This patch fixes the difference in layout. The immediate cause of the
layout difference was that a cell (the second outermost) on the second
page had a height, computed in CalcUnpaginatedBSize, that was large
enough to cause it to need to continue onto the third page. This height
came (via nsTableRowFrame::GetUnpaginatedBSize) from the
UnpaginatedHeightProperty stored on the first-in-flow of its row, on the
first page, stored by CacheRowBSizesForPrinting called in
nsTableRowGroupFrame::ReflowChildren during the reflow of its row group
on the first page, in a special height reflow initiated during the
second-pass constrained-height reflow of the table (still,
second-outermost) on the first page, due to the change being fixed in
this patch.
MozReview-Commit-ID: 3E84VwdXuPs
2017-07-13 05:37:12 +03:00
|
|
|
</div>
|
|
|
|
|
</div>
|
