Converted NS_STYLE_BORDER_STYLE_* consts to enum class. Updated corresponding values to enum class. reduced BCCornerInfo struct values to fit StyleBorderStyle values inside struct. Added defaults to switches that do not fully cover all instances of StyleBorderStyle.
Unfortunately, accepting all BCBorderOwner enum values causes the layout/reftests/table-bordercollapse/frame_above_rules_all.html mochitest to fail. To fix the -Wbitfield-enum-conversion warnings without breaking the test, this patch explicitly masks the BCBorderOwner enum values to preserve the previous implicit truncation. I filed follow-up bug 1508921 to remove this workaround and fix the test.
This enum truncation was reported by clang's -Wbitfield-enum-conversion warnings:
layout/tables/nsTableFrame.cpp:5318:14 [-Wbitfield-enum-conversion] bit-field 'ownerElem' is not wide enough to store all enumerators of 'BCBorderOwner'
layout/tables/nsTableFrame.cpp:5358:16 [-Wbitfield-enum-conversion] bit-field 'ownerElem' is not wide enough to store all enumerators of 'BCBorderOwner'
layout/tables/nsTableFrame.cpp:5374:18 [-Wbitfield-enum-conversion] bit-field 'subElem' is not wide enough to store all enumerators of 'BCBorderOwner'
layout/tables/nsTableFrame.cpp:5385:18 [-Wbitfield-enum-conversion] bit-field 'subElem' is not wide enough to store all enumerators of 'BCBorderOwner'
Differential Revision: https://phabricator.services.mozilla.com/D12382
--HG--
extra : rebase_source : 74c1c3d49e84212ba61c0784f669cadb19f2b4cd
extra : intermediate-source : 2336858d1df479b16e096a9bb5f8eea5008ca9ea
extra : source : 4ab689fc9a368a4c6faaf71169eb72fdc9bb249d
The value of BORDER_STYLE_UNSET will change in patch part 2 when we must shrink the sentinel value from 0xFF to 0xF to fit in the new 4-bit style bit fields.
Differential Revision: https://phabricator.services.mozilla.com/D12381
--HG--
extra : rebase_source : 5d1d27335a4e6219225649c1c6dbecb6ad5b9804
Behavior-wise this only removes the HasAttr(src) check, and adds the IsEmpty()
check to the alt attribute value, since this function is only called for <img>
and <input>.
But it also cleans up a bit.
Differential Revision: https://phabricator.services.mozilla.com/D11194
Behavior-wise this only removes the HasAttr(src) check, and adds the IsEmpty()
check to the alt attribute value, since this function is only called for <img>
and <input>.
But it also cleans up a bit.
Differential Revision: https://phabricator.services.mozilla.com/D11194
--HG--
extra : source : 803b224d52a0940b4fb4b3b9cffc6a1fa6e5d4ee
Behavior-wise this only removes the HasAttr(src) check, and adds the IsEmpty()
check to the alt attribute value, since this function is only called for <img>
and <input>.
But it also cleans up a bit.
Differential Revision: https://phabricator.services.mozilla.com/D11194
Currently, GetSplittableType() is called only in
nsCSSFrameConstructor::CreateContinuingFrame(). The splittable concrete frames
should inherit from nsSplittableFrame, and must explicitly create continuing
frame in CreateContinuingFrame(). Thus, no need to maintain GetSplittableType().
Differential Revision: https://phabricator.services.mozilla.com/D10798
--HG--
extra : moz-landing-system : lando
This patch isn't expected to change behavior; it's just some simplification.
Differential Revision: https://phabricator.services.mozilla.com/D6976
--HG--
extra : moz-landing-system : lando
See the discussion in https://github.com/servo/webrender/issues/1280. I think we
should do this sooner rather than later.
Need to update a couple reftests to hardcode the new colors, waiting on try for
that but should be trivial.
This makes a few more tests pass which are just marked as failure in bug 1487407,
because I implementing the border-collapsing reusing a bunch of Gecko code,
including the table 3d border stuff.
Differential Revision: https://phabricator.services.mozilla.com/D6565
The previous border-collapse beveling implementation assumed that there would
only be one beveled border per side in the whole table, which is... not true at all.
So a bunch of borders ended up clobbering other values in mBevelBorders and
never getting painted.
I'm actually somewhat scarily surprised that only this reftest seems to fail
without this patch...
Here we reuse most of the existing one-off beveling / border rendering support
in nsCSSRendering, and convert the Gecko bevels into a WebRender display list
using rects and borders. This is only remotely possible thanks to Gecko not
supporting dotted / dashed beveled borders :)
This would slightly easier and presumably also more efficient with a triangle
display item in WR instead of (ab)using the border display item to render the
bevel, but this is probably relatively edge-casey so maybe not worth it... In
any case I've left a TODO comment there, that can be a nice followup if we deem
it worth it.
Anyway, I'm _so_ sorry for the border trick, I was this (||) close to go and
rewrite our border collapsing code, but after a few tries I realized it'd take
me a whole lot of time (instead of the day that this has taken me).
Differential Revision: https://phabricator.services.mozilla.com/D4793
Bug 895096 comment 0 recommends using the name `d2a` instead of `p2t`.
Depends on D5368
Differential Revision: https://phabricator.services.mozilla.com/D5369
--HG--
extra : moz-landing-system : lando
This is needed for patch 4.
This is based both on the wording in the spec and the discussion in
https://github.com/w3c/csswg-drafts/issues/2987, and also doesn't
support them for nsMathMLContainerFrame, which is similar to inlines and
ruby.
Differential Revision: https://phabricator.services.mozilla.com/D2815
--HG--
extra : rebase_source : b7e23fb248fa34957ca2d539134e872f5a03f5a8
This builds on bug 1428676 and introduces StyleAppearance, which replaces the
NS_THEME_* constants.
Really sorry for the size of the patch.
There's a non-trivial change in the gtk theme, which I submitted separately as
bug 1478385.
Differential Revision: https://phabricator.services.mozilla.com/D2361
MozReview-Commit-ID: DiSmMWK7Krp
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
An ancient comment from 1998 assures us that GetRect is wrong if there are captions.
The painting code instead uses mVisibleRect which appears to be correct.
MozReview-Commit-ID: 6Lax4sjInJu
--HG--
extra : rebase_source : 79dd527173443fba8d0718c581852d7bfcc47a3c
This is needed only for CSS Grid since in other cases we're
only using IntrinsicISizeOffsets in the inline-axis and
the percentage basis is always indefinite for *intrinsic
sizing*. When calculating the intrinsic size of grid items
in the grid container's block axis however, we do have
a definite size for the grid area in the inline-axis and it
should be used per:
https://drafts.csswg.org/css-grid/#algo-overview
"2. Next, the track sizing algorithm resolves the sizes of
the grid rows, using the grid column sizes calculated in
the previous step."
(Percentage padding/margin for grid items is always resolved
against the grid area's inline-size nowadays.)
This function doesn't use any StackingContextHelper state anymore.
We should make what it does clearer and move it to a better place.
--HG--
extra : rebase_source : 1727be9657169547d842ec9b6887837abedbefdf
This patch basically does:
* remove StyleSetHandle and its corresponding files
* revisit #includes of related header files and change correspondingly
* change nsIPresShell::mStyleSet to be UniquePtr<ServoStyleSet>
* change the creating path of ServoStyleSet to pass UniquePtr
* change other mentions of StyleSetHandle to ServoStyleSet*
* remove AsServo() calls on ServoStyleSet
Some unfortunate bits:
* some methods of (Servo)StyleSet only accepts ServoStyleSheet while
many places call into the methods with StyleSheet, so there are many
->AsServo() added to sheets
MozReview-Commit-ID: K4zYnuhOurA
--HG--
extra : rebase_source : 459e8efeb171adad089d94272e143e8c244bd279
extra : source : 65ba2f174fcf7dba4e59c00ee8908b1bd0820a48
The aSamePointerStructs argument is unused now.
Also, aIgnoreVariables can be true everywhere now, since variable changes can't
generate change hints, and anonymous boxes and such don't care about whether
they really changed or not.
Only one caller cares about struct equality, and that already compares variables
manually as an optimization on the rust side.
We had this optimization inconsistently in some cases but not others.
MozReview-Commit-ID: F2EISKlxR3K
-Wmissing-prototypes is a new optional warning available in clang ToT. It warns about global functions that have no previous function declaration (e.g. from an #included header file). These functions can probably be made static (allowing the compiler to better optimize them) or they may be unused.
Confusingly, clang's -Wmissing-prototypes is equivalent to gcc's -Wmissing-declarations, not gcc's -Wmissing-prototypes. A function prototype is a function declaration that specifies the function's argument types. C++ requires that all function declarations specify their argument types, but C does not. As such, gcc's -Wmissing-prototypes is a C-only warning about C functions that have no previous function *prototypes* (with argument types), even if a previous function *declaration* (without argument types) was seen.
MozReview-Commit-ID: FGKVLzeQ2oK
--HG--
extra : rebase_source : 81e62163bf41a5d5dd87abf5397e6e8c62ed4096
extra : source : 653a9fc279e2f6a6d066474a94a70d65ac703d6b
Some included headers for source code in layout directory are left unused. This
patch merely removes these redundant headers. All of these headers are still
found in use for other code, so all of them and their related cpp files are kept
still.
MozReview-Commit-ID: KCleuWyOV8Z
--HG--
extra : rebase_source : 6e892dcd8ad8c1f56069d4d93bc7124641361232
A table's used width may be different with its computed width. In the past, this
situation wasn't taken into account in process of table reflow, this patch
corrects the positioning of children of a table in this situation.
MozReview-Commit-ID: 4siu2ba0pqG
--HG--
extra : rebase_source : b713baa825151e9a789abcc772d081ff065acaed
Since bevel only appear outmost border of table. I collect all bevel border
and combined them as a single border with four sides.
MozReview-Commit-ID: Bvu8Zf56YDF
Skip files under intl/icu/ because they're imported from third party.
DONTBUILD because this is a whitespace-only change.
MozReview-Commit-ID: GSd6oeFSTO7
--HG--
extra : rebase_source : 38c20bf6099c18b2fcb4c324d470b279addf8891
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
For layers-full mode, we set the backface-visibility to visible because
visibility would be handled by FLB and layers.
MozReview-Commit-ID: CUbeUabfC7K
nsReflowStatus::IsEmpty() assertions are added after DISPLAY_REFLOW in the
beginning of the Reflow().
A few Reflow() implementations have Reset() calls at the end which are left
in place by this patch (with an explanatory comment added to each). These
ending Reset()s are only needed for cases where a non-splittable frame
passes its own nsReflowStatus to a child's reflow method. Just in case the
child leaves a "not fully complete" value in the nsReflowStatus, the
non-splittable parent frame must clear out the nsReflowStatus before
returning, so that its own parent doesn't then try to split it.
MozReview-Commit-ID: 6Jj3jfMAqj4
--HG--
extra : rebase_source : e1fe6a775ad97e16a6d7cc224634ff962ccb0fbf
This ensures the Reflow() call in nsContainerFrame::ReflowChild() is using
an empty reflow status.
MozReview-Commit-ID: K2Ln2i4XkB5
--HG--
extra : rebase_source : ec74a2fece0cda7e61f112e778afe13f128dc76b
In the printing preview, we create continuous table frame if table is too
long to containing in a page. But the default value of
NeedToCalcHasBCBorders is false which means we don't calculate
HasBCBorders for continuous table frame. Thus, the border collapse is
not shown when printing preview.
MozReview-Commit-ID: IqhLSYuWj30
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
No functional changes intended in this patch. It merely simplifies the
additional patch that we'll need to update gecko past WR cset 0bf6655,
and saves some potential manual rebasing work.
MozReview-Commit-ID: Km8dBotP3NQ
--HG--
extra : rebase_source : 77c34ec1cbbc1c0fe4d1971feb131d30c97f0d66
No functional changes intended in this patch. It merely simplifies the
additional patch that we'll need to update gecko past WR cset 0bf6655,
and saves some potential manual rebasing work.
MozReview-Commit-ID: AgMyNapY2Og
--HG--
extra : rebase_source : d8522d8e806522a4a0e8b2cd1669db0374bd5e63