This change should be also fine for the Gecko callers, but please double-check.
MozReview-Commit-ID: 5ZntHeBt5wC
--HG--
extra : rebase_source : d623693f690e933ccc67881795b3e4f5289e9fa4
We were accidentally using the background one for the mask layers list anyway,
and I don't think the overhead of filling the arrays for the two properties
mask layers don't use is a problem.
MozReview-Commit-ID: 7LDiYGrnUd5
--HG--
extra : rebase_source : 573d70e0e8c4d110ca6da2846e6fd2887b1fded2
The "linear time" comment was rendered incorrect by bug 1404181.
And as the body is now only returning a member variable, it's more efficient
and maintainable to just have it to the header.
MozReview-Commit-ID: 4vjB1PyemxR
--HG--
extra : rebase_source : 8089dd66218922a07ffcca9a35f9809522752255
Otherwise we do update keyframes data unnecessarily.
MozReview-Commit-ID: ys4BEF1kxX
--HG--
extra : rebase_source : 725aef9a4be9296bc992f6128be7c62b4c2b01e1
It's good to save some copy constructor calls.
MozReview-Commit-ID: 6TveqwkOvc0
--HG--
extra : rebase_source : 02e678f985c074f6c972cf8478e233aa5e4607db
I don't know why GetInsertionPrevSibling would get the parent wrong.
IsValidSibling handles the frameset case and a lot of the table caption cases.
The table caption cases IsValidSibling can't handle are due to elements which
create frames based on something other than display.
For those cases, while IsValidSibling will return incorrect results, we will end
up seeing that the parent frame is the wrong type after creating the frame
construction items for the new stuff and reframe under WipeContainingBlock.
MozReview-Commit-ID: 5b3L4CB6Oxl
--HG--
extra : rebase_source : c3559dae0b5f4de72fbf5031bdded48f79df6216
There's nothing preventing the flat tree from changing while the document
doesn't have a shell. In that case, we really really don't want to lose track
of elements with stale style data, since then we'll mess up.
It's ok to _not_ clear the style data when the document goes into the BFCache
though, because the document is thrown away if other document runs script and
touches the cached DOM.
MozReview-Commit-ID: 4W3xDAnnLPL
Otherwise we may inappropriately style it or what not. This asserts with the
patches of bug 1414999 plus the cleanup of bug 1418456, since we no longer do
StyleNewChildren (which walks over the flattened tree children).
Too bad that GetXBLBinding is a virtual call in Gecko, probably can do just
MAY_BE_IN_BINDING_MGR...
MozReview-Commit-ID: CNU0YdKeaR0
Now we always restyle the whole subtree for Servo, so we may create another
style context for the bound element.
This trips assertions if we happen to create pseudo-element styles for them.
Since that assertion is pretty useful, just re-get the style context all the
time, which is a cheap operation otherwise.
The CLOSED TREE nightmare should end. This wasn't caught in my try run because
another assertion made the crashtests stop running, apparently.
MozReview-Commit-ID: 6U0phWFvvXO
They're useless now, provided we remove the hack to not traverse XBL-bound
elements on initial styling.
This also allows us to get rid of the fallback case.
MozReview-Commit-ID: AvBVdyF1wb6
We not only need to care about children getting inserted in the flat tree, but
also about children moving _out_ of the flat tree.
In particular, as of right now we may leave stale data on elements when they
disappear from the flattened tree.
We're lucky enough that in 99% of the situations we enter in[1] and that clears
all the stuff, including servo data. But my assertions for bug 1414999 caught
the template / observes case.
Thus, just clear the whole bound element subtree data, and restyle it in the
end, no need for StyleNewChildren. This matches what we do for shadow DOM
(though in the shadow DOM case we do it async in DestroyFramesForAndRestyle).
[1]: https://searchfox.org/mozilla-central/rev/9bab9dc5a9472e3c163ab279847d2249322c206e/dom/xbl/nsXBLBinding.cpp#368
MozReview-Commit-ID: 69A0aR0AFfU
The gecko have two types of mask layer: css mask layer and the regular mask layer.
The hash key of ContainerState::mRecycledMaskImageLayers doesn't contain mask type.
So, we might get a css mask layer when we try to get a regular mask layer. Then, we
will get a nullptr of userData.
This patch add a userData checking in ContainerState::CreateOrRecycleMaskImageLayerFor()
to avoid the problem.
MozReview-Commit-ID: EEUhkctqwR2
Create hit-test info items (if enabled) for each frame that is not
invisible to hit-testing. This is not optimized at all yet, so it
creates a lot of display items if enabled.
MozReview-Commit-ID: LFqoaZ9e99F
--HG--
extra : rebase_source : 8a4a6bf912f88b35f2ed86f9a84ddb74e69bde38
This also adds a flag to the nsDisplayListBuilder to better control
the creation of these items.
MozReview-Commit-ID: BbeRGDjd2ie
--HG--
extra : rebase_source : ec36114d3c7eefffcf9612fc2da1aaf1353c35d8
This introduces a enum bitset type that encapsulates some of the
interesting properties that frames have that make it interesting for
hit-testing in the compositor. This type is designed so it can be sent
directly to webrender and gotten back in the hit-test.
MozReview-Commit-ID: GCxV7ZaoJd1
--HG--
extra : rebase_source : a9cc5ecfc7c5baeab2f6e08cd2ee2c2a7756e20c
The default value is 'px'. The alternative value is 'pt', but it's not clear
that changing it to 'pt' will actually work sensibly.
It was first suggested that this pref be removed 17 years ago, and it doesn't
appear to have become more useful since then. It's not set anywhere. Let's
remove it.
--HG--
extra : rebase_source : 9dbb44102db2bcc5ba6c2f354dc35d8a86acd8f3
This patch amends an existing workaround, but as the NOTE there says,
we should have pulled up those floats and reflowed them somewhere
(and pushed them again potentially, and then we wouldn't be COMPLETE).
It's unclear to me where that pull-up is supposed to happen though.
MozReview-Commit-ID: ES2rb1l7jyi