The only reason not to do that is when there's after content in there. We know
that there isn't really any ::after content, since it would've been handled by
FindNextSibling, so we know we're performing a real append.
MozReview-Commit-ID: ExoPolZy4gG
It was exposed during stylo implementation but it should be behind
`layout.css.grid-template-subgrid-value.enabled` pref.
MozReview-Commit-ID: DqrU6zYgdES
--HG--
extra : rebase_source : 14859f5912faff9cf2daf9b10409114e853bab6d
This also makes the rule map not process all the stylesheets for the document,
which would be a mess with shadow DOM.
Far from the final, ideal state, but hey, progress.
MozReview-Commit-ID: 7TrifME9VZ
This also makes the rule map not process all the stylesheets for the document,
which would be a mess with shadow DOM.
Far from the final, ideal state, but hey, progress.
MozReview-Commit-ID: 7TrifME9VZ
It is expected to use 64-bit for all the restyle generation counters, since the
getter methods all return uint64_t type at present. However, we're using uint32_t
for the actual counter variables, which means the potential overflow issue is not
avoided.
In this patch, we use 64-bit for the restyle generation counters, so the overflow
issue can be avoided as expected.
MozReview-Commit-ID: 2y2afIcuwvc
--HG--
extra : rebase_source : 3fe64d7d3fc00fa1031eef9f0c15b64405435dfd
This EnsureEventualDidPaintEvent() creates software timer. But this timer will
bring several intermittent tests fail. For example, if we want to check the
compositor animation property. If test receives MozAfterPaint of the timer,
there doesn't have animation property on compositor, as result of this, a test
will fail.
I think we don't need to create this timer each time since current painting is
happening synchronously under the refresh driver.
[1] https://searchfox.org/mozilla-central/rev/919dce54f43356c22d6ff6b81c07ef412b1bf933/layout/base/nsPresContext.cpp#189
MozReview-Commit-ID: Hb7UEITer5t
--HG--
extra : rebase_source : 7aee1eced01813907ab0c3e5dff80e90261c0815
Setting the 'layout.display-list.retain.verify' gfxPrefs implies
'layout.display-list.build-twice', and then compares the retained-built tree
to the non-retained one, and outputs differences&trees to the terminal.
MozReview-Commit-ID: 3dnyIUTbtH8
--HG--
extra : rebase_source : 36a6b8f029d0bd1339557e7c630906311ecf1254
The change is mostly copied from GeckoRestyleManager::AttributeChanged.
It is not clear to me whether it's worth moving it to the superclass so
that we don't duplicate the code. If we are removing the Gecko code in
short term, it probably doesn't matter.
It is also not clear whether we should port other code from that method
to ServoRestyleManager.
MozReview-Commit-ID: Fd1nbwgLGa1
--HG--
extra : rebase_source : 7bba8907fa7e57695a8294cf9277804fbe23ff8f
This also moves the function from nsLayoutUtils to be a function on the
ASR itself, which seems more appropriate.
MozReview-Commit-ID: 88lUmYi80P0
--HG--
extra : rebase_source : 3f7e4f875c3267f9f4c5c67e720912ceedb25719
We don't use aStyleContext inside nsFrameConstructorState::AddChild(), so I
think we should remove it.
MozReview-Commit-ID: JQUlEDyVcUj
--HG--
extra : rebase_source : 0569c6c010e98915bb288da16457e1d3c62403cd
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
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
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
Find out where we use MayHaveTransformAnimation in EffectSet
and change them to MayHaveTransformAnimation in nsIFrame.
MozReview-Commit-ID: GhkztK8JtNa
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
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
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
This is a large patch which tries to switch many of the external consumers of
nsGlobalWindow to instead use the new Inner or Outer variants.
MozReview-Commit-ID: 99648Lm46T5
Fix warning: annotate this function with 'override' or (rarely) 'final'
MozReview-Commit-ID: GovhMo2V2q5
--HG--
extra : rebase_source : eb901d9771f7d1d1221d075f236d9b894a6d257d
Fix warning: 'virtual' is redundant since the function is already declared
'override'
MozReview-Commit-ID: Kps9ZZoFniI
--HG--
extra : rebase_source : aed811d199ed9d977648656ef9175ccac26206b8
Fix warning: the parameter 'aHints' is copied for each invocation but only
used as a const reference; consider making it a const reference
MozReview-Commit-ID: 6CyT6gxVgES
--HG--
extra : rebase_source : e93f4eee24a2ef1e27dcfc43725fb5600f1b2d5b
Fix warning: use '= default' to define a trivial destructor
I added #include "nsDocShell.h" because I got an error "incomplete type
'nsDocShell' used in nested name specifier." After that, some files like
nsCanvasFrame.cpp fails to compile because they include
AccessibleCaretEventHub.h. Hence the moz.build changes.
MozReview-Commit-ID: BYZx7txvkSn
--HG--
extra : rebase_source : 2a4e8c25eb1c596486d540f2a5a34a00dc675881
InsertFirstLineFrames has been dead for a long time, and I don't think it's
worth to keep it around. It's in the VCS history anyway.
MozReview-Commit-ID: FetYB6nf38D
--HG--
extra : rebase_source : bc56cdec7a4e45c7ea1d8cf6354a5a6dc349ac29
This makes it a bit more straight-forward to change the system font scale,
preserving the sync MediaFeatureChanged event.
This also avoids notifying media queries when the shell is not initialized.
In particular, the patch in bug 1404545 allows calling MediaFeatureValuesChanged
on a still-initializing pres-shell. This is nasty, and all this initialization
order is kind of a mess, but I'm not reworking it for now...
Also, this drops the invalidation of font-inflation when a doctype is added to
the document. GetViewportInfo() already relies on the doctype not changing, as
noted in a comment.
MozReview-Commit-ID: Knw7dM1B04Y
This is a significant rework of how do we compute the insertion point of a
node.
We handle pseudos in the same function instead of out of band, and also recurse
up when the parent has display: contents, which simplifies the code IMO.
MozReview-Commit-ID: 1rSfv1Tq5gO
Rendering at least aDirtyRect is more important than staying under
aPrerenderSize, so that's what we do.
MozReview-Commit-ID: 8Ze1biaNzqX
--HG--
extra : rebase_source : b04aedafa8432004a716f0cb4b4c5dc6c418dfda
This actually fixes bug 1251799, and bug 1359656. Turns out the bug it was
hiding was this one! :)
MozReview-Commit-ID: KCSsu4T0PER
--HG--
extra : rebase_source : f0619815cb5e4858d1e0669463bcbbdc32f786c5
There's no reason I can think of this wouldn't work, and try is totally green
without it.
MozReview-Commit-ID: K9QXbAOFu3A
--HG--
extra : rebase_source : 13eb1928d2b31f451610ca633d12cf912670e4e4
And unthrottle them on every 200ms just like we do for transform animations on
the compositor. To unthrottle the transform animations properly, we need to
update UpdateLastTransformSyncTime each time we compose the style for the
animations instead of updating it when we send the transform animation to the
compositor. That's because display item for transform is built even while we
are throttling the transform animations for some reasons, so if we updated the
last transform sync time there, the time will not match what it should be.
MozReview-Commit-ID: GwMzJqUlzd2
--HG--
extra : rebase_source : 09e379191970687a9f35aead871acf450c63813e
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
Note that I'm intentionally *not* leaving a blank line between the license
block and the "IWYU pragma" line, in nsDisplayItemTypesList.h. This matches the
prevailing style that I found in other files that have "IWYU pragma" lines.
I copied the boilerplate comment directly from the Coding Style MDN page:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
MozReview-Commit-ID: ACoHkDFe8Z3
--HG--
extra : rebase_source : 374d28fea72cfb76043bde724120877b15092d01
It's a sub-class of nsAtom, useful for cases where you know you are dealing
exclusively with static atoms. The nice thing about it is that you can use
raw nsStaticAtom pointers instead of RefPtr<>. (In fact, the AddRef/Release
implementations ensure that we'll crash if we use RefPtr<nsStaticAtom>.)
MozReview-Commit-ID: 4Q6QHX5h44V
--HG--
extra : rebase_source : e4237f85b4821b684db0ef84d1f9c5e17cdee428
I'm drive-by removing the comment about the frame tree state because I looked
into it, and the answer is: we properly restore it.
The gotcha is that we retain it too much, indeed, we retain it enough that it
can leak. See bug 1397239.
MozReview-Commit-ID: LP6bXkduEZ4
--HG--
extra : rebase_source : f7e18fc35e48b75c07fcc84b939614d379926828
Most of this change is just fiddling with function signatures so that they take
a LayerManager* instead of a Layer* (or in some cases, both). This allows
the WebRender codepaths to pass a WebRenderLayerManager* instead of having to
produce a Layer* which it doesn't have.
MozReview-Commit-ID: Fb0C8OUVDin
--HG--
extra : rebase_source : e4c3324cfa20c295db85d5c09df8d8d77865bb6a
Emilio Cobos Álvarez
Matt Woodrow
Olli Pettay
Gurzau Raul
Nazım Can Altınova
Mats Palmgren
Boris Zbarsky
shindli
Andrew Osmond
Brindusan Cristian
Edgar Chen
Dorel Luca
Jeremy Chen
Sebastian Hengst
Ciure Andrei
Mantaroh Yoshinaga
Gerald Squelart
Xidorn Quan
Botond Ballo
Kevin Jones
Cameron McCormack
Tiberius Oros
Kartikaya Gupta
Nika Layzell
Oriol Brufau
James Willcox
KuoE0
Coroiu Cristina
Jonathan Kew
Ting-Yu Lin
Miko Mynttinen
Markus Stange
Brendan Dahl
Nicholas Nethercote
Narcis Beleuzu
Noemi Erli
Ya-Chieh Wu
Chris Peterson
Andreea Pavel
Brad Werth
Ryan VanderMeulen
Hiroyuki Ikezoe
Joel Maher
Daniel Holbert
Ray Lin
Jeff Muizelaar
Andrea Marchesini