This class was used back when we didn't have a base class for CSSStyleSheet
and ServoStyleSheet. Now it's unused.
MozReview-Commit-ID: 8xaMAA3Opf7
--HG--
extra : rebase_source : fe507762ba80ab54ca2a87e84faa8bc1a1a8590f
This is a prerequisite change for passing pseudo element to
Servo_StyleSet_GetBaseComputedValuesForElement which will be done in the next
commit.
MozReview-Commit-ID: HEGF2wjBGEP
--HG--
extra : rebase_source : 58d5991f3e4559c4215292ee8c48f79b38acb54a
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
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
There are many helper methods and structs in nsGlobalWindow.cpp. Many of these
are used by only the inner or only the outer window, while some are used by
both. In the case of the items used by both, I extracted them into
nsGlobalWindow.cpp, which includes nsGlobalWindowInner.cpp and
nsGlobalWindowOuter.cpp as the compilation unit entry point.
In the case of items used by just one or the other, I removed them from the
other file, and deleted the bodies of functions which used them, replacing them,
with a MOZ_CRASH.
This gets gecko building again, so that we can make further incremental
improvements.
MozReview-Commit-ID: 8QnJ1PX6TAO
--HG--
extra : rebase_source : 0eac00ad757f825a22a1af95d0a01d6fa92d824d
Find out where we use MayHaveTransformAnimation in EffectSet
and change them to MayHaveTransformAnimation in nsIFrame.
MozReview-Commit-ID: GhkztK8JtNa
There are two places where I have to cache the status of MayHaveOpacityAnimation
and MayHaveTransformAnimation. First place is in |nsIFrame:init()| where an
element is associated with a frame. Second place is in
|KeyframeEffectReadOnly::UpdateEffectSet()| where the script can add animations
on element.
btw I keep the original two flags of MayHaveOpacityAnimation and
MayHaveTransformAnimation in EffectSet because there is no guarantee that
an element has been associated with a frame when we call to |UpdateEffectSet()|.
But we still want to keep the benefits that we can quickly look up
MayHaveOpacityAnimation or MayHaveTransformAnimation. So I keep them in
EffectSet and transfer the status into nsIFrame when we bind an element
to a frame in nsIFrame:Init().
MozReview-Commit-ID: JDwyAQQTKA7
In the current implementation, when hyphens property is set to auto, we do some
math to determine the index of text fragment, so we can check whether a character
is an explicit hyphen. However, the math calculation is not reliable, and it is
not easy to calculate the fragment index when there are more than one fragments
in a gfxTextRun, e.g., a paragraph which consists multiple inline elements.
In this patch, we simply use GetOriginalOffset() to get the position relative
to the current text fragment, and scan/detect explicit hyphens correctly.
MozReview-Commit-ID: JIg3tdpViRH
--HG--
extra : rebase_source : a6ac03914badd2f2dcd238186a6653e8660bc116
Add reftest to ensure that hyphenation breaks are not affected if there are
multiple inline elements inside a paragraph.
MozReview-Commit-ID: Jmh0LPgjCVF
--HG--
extra : rebase_source : 985ae8c3f878c0275b3dab6876bbc544ccb8cc36
Many members of nsFrameSelection are uninitialized, which could cause some
potential issues. In this patch, we use per-member defaults for nsFrameSelection,
and make sure we initialize all the members properly.
MozReview-Commit-ID: H9MMlSZoinh
--HG--
extra : rebase_source : c68ac4f61a687fd981363efa924fdbb2e0804b10
In this patch, we move the member assignments in nsFrameSelection's constructor
to nsFrameSelection's class definition. This is a pre-patch for switching
nsFrameSelection to use per-member defaults. With this patch, all the uninitialized
members can be tracked easily.
MozReview-Commit-ID: 1HhTDlV73QN
--HG--
extra : rebase_source : f97f7a46ba70e1f36f4812591d73b64061cf0c9e
Sometimes, when adjusting the frame construction procedure, the relationship
between parent and child would be unexpected. So, adding the parent info
into that allows us to notice the expected result.
MozReview-Commit-ID: 8DWOXing463
--HG--
extra : rebase_source : 6d45b0fc40a90ca141a267ec7f152a8bd6d33932
There's no need to set anon boxes reset properties to their defaults.
Also, there's no need to use !important, since they have no other rules. There's
::-moz-pagecontent which is tricky, because it can be affected by @page rules,
but only margin properties are allowed on those.
MozReview-Commit-ID: Gtl9jTLYyXA
--HG--
extra : rebase_source : c151a61f112a7e2fe402663bb32e76514ddb69c9
This makes it API compatible with std::ostream, which it replaced. This silences a rare crash.
MozReview-Commit-ID: JoNo1qRCb0n
--HG--
extra : rebase_source : bcdce5d57fd0620610a5c797045d95b44fbc9099
The pref "browser.ignoreNativeFrameTextSelection" was used only by B2G, and
currently not enabled elsewhere, so this code is dead now. Also, this
functionality is obsoleted by AccessibleCaret.
MozReview-Commit-ID: 2kHYXLueFH5
--HG--
extra : rebase_source : d610dd7f4c3aa48fbcae0d9bed4736b89cf7b659
This follows from the previous patch; these values feed into UpdateMinMaxScale
as well, which explicitly wants to use floats, so there's no point in creating
doubles. The source of this information is also a float-based matrix.
MozReview-Commit-ID: LPk4Xm9AaJJ
--HG--
extra : rebase_source : d7714755fb1078880133d6f044cc9bc7743439ee
The code in ComputeSuitableScaleForAnimation feeds its double-based
computation results into GetSuitableScale, which takes and returns
floats. Also the double-based computation that it's doing involves
calling UpdateMinMaxScale a bunch which explicitly uses the float
variant of std::min and std::max. And all of this is used from
ChooseScaleAndSetTransform which does other things like call a
"RoundToFloatPrecision" function, and casts the final values to
floats before setting the layer's prescale. So let's just use
floats all the way through.
MozReview-Commit-ID: BE3WC5hv89d
--HG--
extra : rebase_source : 987d9d69ec2a200ed68c59bae5fae1115713a94c
This code was written before the ScaleFactors() function was available on
the float-based gfx::Matrix, which I presume is why it was written to
convert the matrix to the double-based variant and store the scale as
doubles. We don't need to do that any more.
MozReview-Commit-ID: EoWLpny8g61
--HG--
extra : rebase_source : 4cac59121961bfb35359def042ac4b0200a85312
The code here feeds into gfxContext::mTransform which is float-based, so
using double-based rects and matrices here is unnecessary.
MozReview-Commit-ID: CbeMM8003DA
--HG--
extra : rebase_source : 735d5c880cca36b9e9bea6cb0c94825b6a1c4597
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
I believe this is a typo. This fix will not affect the existing frame dump result
because the input parameter, i.e., aTo, has been initialized to empty string by
the caller before calling. So, the first line of nsIFrame::ListGeneric can be
written as:
a) aTo =+ aPrefix;
b) aTo += aPrefix;
c) aTo = aPrefix;
and all three results are the same at present.
In this patch, we fix the typo by choosing (b) to make it align the rest parts
of nsIFrame::ListGeneric.
MozReview-Commit-ID: CHJDyVSJj5W
--HG--
extra : rebase_source : 2569f2ebaf72a1a4784cf58a76f14382811412e7
That way we don't bust the build (for some reason the ASAN build choked in
ResponsiveImageSelector, I suspect due to missing includes).
MozReview-Commit-ID: 6I6Q7jiAFr0
This needs to dumb down the parsing in order to match what we do in Gecko and
pass more tests.
The remaining tests are just because of calc() in media queries and "or" media
expressions.
MozReview-Commit-ID: CXGdYVbojBL
Current fuzzy-if of reftest will use last specified fuzzy range which condition
is true. In this test case, all fuzzy-if condition is true and doesn't order in
descending. We should sort this order in descending order.
MozReview-Commit-ID: 2foJaqFAOwG
--HG--
extra : rebase_source : 9a7311eb7ded5556bd9e075c9da66c0db047c95a
nsBlockFrame::DoRemoveFrame destroys the continuations in first-to-last
order. Unfortunatley, this means that frames for anon/generated content
that were pushed to a later continuation may already be unbound by
the time we destroy its frame. This patch fixes that by collecting
anon/generated content from all the continuations, rather than from
each continuation separately.
MozReview-Commit-ID: LPBSoqjfjnA
The core of this change is in gfxContext.*:
- change gfxContext::CurrentMatrix() and gfxContext::SetMatrix() to
return and take a Matrix respectively, instead of converting to
and from a gfxMatrix (which uses doubles). These functions therefore
will now match the native representation of the transform in gfxContext.
- add two new functions CurrentMatrixDouble() and SetMatrixDouble() that
do what the old CurrentMatrix() and SetMatrix() used to do, i.e.
convert between the float matrix and the double matrix.
The rest of the change is just updating the call sites to avoid round-
tripping between floats and doubles where possible. Call sites that are
hard to fix are migrated to the new XXXDouble functions which preserves
the existing behaviour.
MozReview-Commit-ID: 5sbBpLUus3U
Add an intermediate step in old-configure.in for setting up
BINDGEN_CFLAGS (renamed to BINDGEN_SYSTEM_FLAGS), so we can add whatever
flags we like (e.g. for system libaries with their includes in
non-standard places) at a later point.
We now set EventRegionsOverride flags on ref layers only, so
there's no need to have the APIs to set it on container layers in
general.
MozReview-Commit-ID: JKU4UXvdR2e
--HG--
extra : rebase_source : 77f49787e8953520dc56ea4a8f9286b35d6942b8
As with the previous patch, instead of setting the override on the root
layer, we set the flag on the nsDisplayListBuilder before building the
display list, and the flag automatically forces all event regions
display items to use their dispatch-to-content region instead of any
other regions.
Both the WebRender and non-WebRender codepaths were setting the override
flag on their root layers and don't need to any more.
MozReview-Commit-ID: 1cz0ahqwkOm
--HG--
extra : rebase_source : 3292951aca97fd1a355c2fae5b0ab42d2064c548
The mechanics of this change is fairly straightforward - instead of setting the
override on the layer corresponding to the in-process subdocument, we just set
the flag on the display list builder; that flag is already checked when building
the layer event regions for descendant nsIFrames.
As a side-effect, we also don't need to force a layer for in-process subdocuments
just because they have document-level APZ-aware listeners. One of reasons we were
doing so before was so that we would have a layer to stash the override flags on
but now we don't need that any more.
Note that out-of-process subdocuments are not affected; for those cases
the nsSubDocumentFrame delegates BuildDisplayList to
RenderFrameParent/nsDisplayRemote, which will still set the overrides on
the RefLayer that is created.
MozReview-Commit-ID: DZWglE4e62p
--HG--
extra : rebase_source : 78494a5cbfd0dfecb5f2262e5c1b3dc5367c5d55
We now set EventRegionsOverride flags on ref layers only, so
there's no need to have the APIs to set it on container layers in
general.
MozReview-Commit-ID: EX57VvaZv8A
--HG--
extra : rebase_source : 7ea4c8bb2716821bf7069158fdf9729fb6137a35
As with the previous patch, instead of setting the override on the root
layer, we set the flag on the nsDisplayListBuilder before building the
display list, and the flag automatically forces all event regions
display items to use their dispatch-to-content region instead of any
other regions.
Both the WebRender and non-WebRender codepaths were setting the override
flag on their root layers and don't need to any more.
MozReview-Commit-ID: KQV3w2nvlgs
--HG--
extra : rebase_source : 5be30af2d928117519296ec238eac91139986531
The mechanics of this change is fairly straightforward - instead of setting the
override on the layer corresponding to the in-process subdocument, we just set
the flag on the display list builder; that flag is already checked when building
the layer event regions for descendant nsIFrames.
As a side-effect, we also don't need to force a layer for in-process subdocuments
just because they have document-level APZ-aware listeners. One of reasons we were
doing so before was so that we would have a layer to stash the override flags on
but now we don't need that any more.
Note that out-of-process subdocuments are not affected; for those cases
the nsSubDocumentFrame delegates BuildDisplayList to
RenderFrameParent/nsDisplayRemote, which will still set the overrides on
the RefLayer that is created.
MozReview-Commit-ID: GTy9BmVVZ9q
--HG--
extra : rebase_source : be321091d6b5fe4b66738f2deeffbcfa6af0b521
Cameron McCormack
Hiroyuki Ikezoe
Matt Woodrow
Coroiu Cristina
Bas Schouten
Jonathan Kew
Emilio Cobos Álvarez
Ting-Yu Lin
Miko Mynttinen
Gerald Squelart
Brindusan Cristian
Cosmin Sabou
Joel Maher
Markus Stange
Sebastian Hengst
Andrew Osmond
JerryShih
Jan de Mooij
Ciure Andrei
Ethan Lin
Kartikaya Gupta
Nicholas Nethercote
Mats Palmgren
Csoregi Natalia
Gurzau Raul
Narcis Beleuzu
Xidorn Quan
Nathan Froyd
Nika Layzell
Boris Zbarsky
Jonathan Watt
Noemi Erli
Brad Werth
Ya-Chieh Wu
Botond Ballo
Jeremy Chen
lochang
KuoE0
Brendan Dahl
Ed Lee
Alex Gaynor
Margareta Eliza Balazs
Mantaroh Yoshinaga
Andreea Pavel
Ryan Hunt
Ryan VanderMeulen
Andrea Marchesini
Jason Kratzer
Milan Sreckovic
Chris Peterson
Mike Conley
Geoff Brown
Tommy Kuo
Phil Ringnalda
Neil Deakin
Kyle Machulis
Timothy Nikkel
David Anderson