Before this change, we used eColGroupContent for both colgroups created by table-column-group elements and anonymous colgroups wrapping table-column elements. eColGroupAnonymousCell was used for colgroups created to handle cells that are not in any other colgroup already. eColGroupAnonymousCol was unused.
In our UA sheet the only style we apply to ::-moz-table-column is "display: table-column".
Per spec, the only styles that apply to table columns are border props,
background props, 'width', and 'visibility'.
The only one of those that inherits is 'visibility'. And the only relevant
value per spec is "collapse". But an anonymous column can only be "visibility:
collapse" in Gecko right now if its colgroup is, and then the colgroup will get
collapsed away as a whole. So it doesn't matter whether the column inherits the
visibility style.
In practice, we do something special for "hidden" on a table-column as well,
during display list building, which affects hit-testing. Per
https://github.com/w3c/csswg-drafts/issues/1763 it's not clear that we should be
doing this at all, but for now we just keep our existing behavior and ensure
that the parent colgroup's visibility style is taken into account for anonymous
columns when building display lists.
There's no real reason to restrict this to LayerSize, since we use
use Layer and LayoutDevice coordinate spaces interchangeably for
webrender. With the templating of the function the compiler doesn't know
what type to use for {0, 0} so I added a new function to deal with that.
MozReview-Commit-ID: BA83Sy9UjYH
--HG--
extra : rebase_source : 15e5b31d0275628713c5eb584d622d22485dfda9
There's no real reason to restrict this to LayerSize, since we use
use Layer and LayoutDevice coordinate spaces interchangeably for
webrender. With the templating of the function the compiler doesn't know
what type to use for {0, 0} so I added a new function to deal with that.
MozReview-Commit-ID: KyabB6P6LiA
--HG--
extra : rebase_source : d5fff8f21a17c433d3c8c580fdd3153140d61545
Before bug 929484, border-radius on row groups, rows, column groups,
or columns don't apply to the background of each cell, yet the
border-radius on the cell itself does. After bug 929484, the behaviors
changed. In this patch, I tried to revert the behaviors of border-radius
on table row groups, rows, column groups, or columns back to
what happened before bug 929484.
MozReview-Commit-ID: 1Xg1qHde3lk
--HG--
extra : rebase_source : ff08f8390ff910fe8c141a75275134f77a1cec3e
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
I noticed this while debugging the assertion count failure of
layout/base/crashtests/470851-1.xhtml . It doesn't help that failure,
but it still seems like the safe thing to do.
MozReview-Commit-ID: 6xHxUJCjUHh
Sebastian Hengst
Neerja Pancholi
Wes Kocher
Boris Zbarsky
Milan Sreckovic
Kartikaya Gupta
Sylvestre Ledru
Jonathan Watt
Matt Woodrow
Emilio Cobos Álvarez
Tobias Schneider
Bevis Tseng
Morris Tseng
Ya-Chieh Wu
Cameron McCormack
Ryan Hunt
Manish Goregaokar
L. David Baron
Carsten "Tomcat" Book
Ehsan Akhgari