The clipping code uses gfxContext::GetClipExtents which calls gfxContext::GetDeviceOffset
and DrawTarget::GetSize. The former was previously not being intialized, while the latter
was explicitly unimplemented. This patch fixes both of those facts.
Otherwise, enabling this functionality has been made trivial by several upstream patches
in webrender (the most recent being glenn's work on unifying shadows which eliminated
the buggy text-shadow shader code that was blocking this).
MozReview-Commit-ID: B1AlG3o4XQS
--HG--
extra : rebase_source : 2043c9c781f507c5d02041420145b1a5c59c0bb2
Currently in ContainerState::SetupScrollingMetadata we call
ComputeScrollMetadata for every layer and for each ASR in the layer's
clip chain. If there are many sibling layers with the same clip then
this is largely wasted work.
This change makes us cache the most recently calculated result, and
only recalculate if the ASR or clip is different.
There was a small portion of ComputeScrollMetadata that must actually
be executed for every layer and ASR in its clip chain. This has been moved
to a separate function, ClipLayerToDisplayPort, that is still called
every time.
MozReview-Commit-ID: 7Zzblmimtc5
--HG--
extra : rebase_source : d39908b2be2565d22079b3e5e8df56316159a918
This improves the DisplayList Mutate Talos test by about 5% on windows, as well as numerous smaller improvements on DisplayList heavy tasks.
MozReview-Commit-ID: tlEtPjqWI4
Assuming we call MarkIntrinsicISizesDirty in the appropriate scenarios, this
patch shouldn't change behavior - it just caches these values so we don't
needlessly recalculate them.
MozReview-Commit-ID: 8QY4AZJXshy
--HG--
extra : rebase_source : a7c87b03ac8240ba71efd2198ce1976d96c91f64
This patch does not change behavior; it just merges the implementations of
these two functions into a single common function.
MozReview-Commit-ID: BqsRt3p2NQT
--HG--
extra : rebase_source : e8792f2bed3fd0708ffb38b91cf15a78cb6fbd59
This method is not a virtual call, and also looks nicer.
This patch was mostly generated by a Python script, but I manually
cleaned up the code in a few places where statements didn't need to be
split across multiple lines any more.
MozReview-Commit-ID: 8JExxqSRc59
--HG--
extra : rebase_source : df6330a89e8d65dfe7a6fda0c8cb9f9732302efc
This brings us into alignment with the spec and makes us pass some web-platform
tests, along with the reftests that I've included for this bug.
MozReview-Commit-ID: KoKPi18svGE
--HG--
extra : rebase_source : f00dd814238afd4b09bdcb75b22ea249162252b8
This patch doesn't change behavior.
It simply makes us share code/data for two different cases that both ended up
producing mainAxisCoord->GetUnit() == eStyleUnit_Auto. Now, they'll *both* use
the same static nsStyleCoord to represent this "auto" value.
Originally, in one of these cases ("flex-basis:auto;[main-size-property]:auto),
we left the mainAxisCoord untouched. Now we'll point it at this dummy 'auto'
value. Either way we end up with mainAxisCoord->GetUnit() == eStyleUnit_Auto,
so the behavior doesn't change.
The next patch in this series will make further changes to one of these spots,
as noted in the "XXXdholbert" code-comment included here.
MozReview-Commit-ID: 5ClfbNHuKhO
--HG--
extra : rebase_source : 17efe1e9f721324d6182db654e601727c791800b
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.)
And make nsIFrame its only caller, modulo a safety assertion.
The safety assertion will be removed at the same time as the pres context
member, since the only purpose of it is to ensure we don't keep a pres context
reference for too long.
MozReview-Commit-ID: CD5zOHVO9ub
And make nsIFrame its only caller, modulo a safety assertion.
The safety assertion will be removed at the same time as the pres context
member, since the only purpose of it is to ensure we don't keep a pres context
reference for too long.
MozReview-Commit-ID: CD5zOHVO9ub
This is mostly code removal, changing GetDisplayContentsStyle(..) checks by an
FFI call to Servo.
The tricky parts are:
* MaybeCreateLazily, which I fixed to avoid setting bits under display: none
stuff. This was a pre-existing problem, which was wallpapered by the
sc->IsInDisplayNoneSubtree() check, which effectively made the whole
assertion useless (see bug 1381017 for the only crashtest that hit this
though).
* ContentRemoved, where we can no longer know for sure whether the element is
actually display: contents if we're removing it as a response to a style
change. See the comment there. That kinda sucks, but that case is relatively
weird, and it's better than adding tons of complexity to handle that.
* GetParentComputedStyle, which also has a comment there. Also, this function
has only one caller now, so we should maybe try to remove it.
The different assertions after DestroyFramesForAndRestyle are changed for a
single assertion in the function itself, and the node bit used as an
optimization to avoid hashtable lookups is taken back.
MozReview-Commit-ID: AZm822QnhF9
Also switch the XPCOM-y version of EventTarget::AddEventListner to a
Nullable<bool> for aWantsUntrusted.
The three-arg overload of AddEventListener in ContentFrameMessageManager was
never called, so all the AddEventListener overloads there are not needed.
MozReview-Commit-ID: 4IhqHmPVWzE
We can't have a null content in
ScrollbarActivity::StopListeningForScrollAreaEvents, because only viewport
frames have a null GetContent().
MozReview-Commit-ID: 9iAg0ivVqqG
And then fix up everything else that needs to change as well.
MozReview-Commit-ID: GDMfERqdQAc
--HG--
extra : rebase_source : 01fe06c3182245a409099a53383d92bf4fa0155c
When we finish decoding an image frame, we need to trigger reflow for the
frame containing a float with shape-outside: <image>, and delay the firing
of the document's onload event until that reflow is complete.
2018-01-25 14:56:43 +08:00
Ting-Yu Lin ext:(%2C%20Brad%20Werth%20%3Cbwerth%40mozilla.com%3E)
When we finish decoding an image frame, we need to trigger reflow for the
frame containing a float with shape-outside: <image>, and delay the firing
of the document's onload event until that reflow is complete.
2018-01-25 14:56:43 +08:00
Ting-Yu Lin ext:(%2C%20Brad%20Werth%20%3Cbwerth%40mozilla.com%3E)
This patch adds three test cases;
1) Animation on position:absolute element in a zero-height iframe
This animation should be throttled.
2) Animation on a non-zero width and hight position:absolute element but whose
parent has a zero height
This animation should NOT be throttled since the animation is visible
3) Animation on a zero-height position:absolute element whose parent also has
zero height.
This animation should be throttled since the animation is invisible
The first test fails without this fix and passes with the fix.
The second one passes regardless of the fix
The third one is marked as 'todo' since it doesn't pass with this fix.
MozReview-Commit-ID: 8pNUFQ71ivj
--HG--
extra : rebase_source : d1d37e5324247efc20a39d86a0f8849450cc7533
BACKGROUND:
Early in flex layout, we have to resolve the 'flex-basis' value to produce the
"flex base size" (basically, the flex-basis resolved to an absolute length).
This resolution happens in two "phases" (which both happen within
nsFlexContainer::GenerateFlexItemForChild()):
First phase: we try to resolve the flex-basis by creating a ReflowInput for the
flex item (which gets us some other things as well). Under the hood, we use
the flex-basis when resolving this ReflowInput's main-axis size. The code for
this lives in nsFrame::ComputeSize (and in
nsFrame::ComputeSizeWithIntrinsicDimensions, via some frame classes' overrides of
ComputeSize).
Second phase: If the first phase didn't get us a definite size, then that means
we have to do reflow to measure the content size & produce a resolved flex base
size, which we do via ResolveAutoFlexBasisAndMinSize().
NOTES ON THIS PATCH:
To add 'flex-basis:content' support to layout, this patch only needs to modify
the first phase discussed above. If it turns out we also have some second-phase
work to do (i.e. if we need to do reflow to resolve 'flex-basis:content'), this
patch causes that reflow to happen by simply making us use eStyleUnit_Auto in
the main axis's nsStyleCoord in the first phase. (And then, if that 'auto'
nsStyleCoord really does require reflow, then that first phase will end up
producing an unconstrained main-size in the flex item's ReflowInput, which will
automatically trigger the second phase.)
MozReview-Commit-ID: 2nH4Fh78C81
There's been a clarification to the spec text that this comment was worried about:
https://github.com/w3c/csswg-drafts/issues/2316
And with that clarification, this comment is no longer applicable.
This patch should not affect behavior.
Logic-wise: the idea behind this patch is to behave as if the
'usingFlexBasisForHeight' variable were always false, which in turn lets us
remove an "if (!usingFlexBasisForHeight || ...)" check, because it trivially
passes when that bool is false.
Background on this special case & why we can remove it:
=======================================================
In the original flexbox implementation, we had some special-case code to be
sure we didn't end up swapping in e.g. "flex-basis:-moz-min-content" for
"height" in these ComputeSize functions, because that was a scenario that
previously would've been prevented at the parser level (height:-moz-min-content
is rejected for now), and hence may not have ended up being handled robustly.
However, nowadays it'll be handled just fine in these functions, and will
produce the same result as our special-case exception tries to achieve.
In particular, for a nsFrame that is a flex item in a flex container with a
vertical main axis (the scenario that these special cases are catching):
- If the (vertical) main axis is this nsFrame's inline axis (i.e. if this
nsFrame has a vertical writing-mode), then Stylo actually converts
enumerated flex-basis values like "-moz-min-content" to "auto" when
producing the computed values that layout sees. So it's not actually
possible for layout to see a computed "flex-basis" of -moz-min-content, in
that scenario.
- Otherwise, i.e. if the (vertical) main axis is this nsFrame's block axis,
then these ComputeSize functions will now end up getting an enumerated
"blockStyleCoord" (really pointing to flexBasis), but that'll still end up
being treated like 'auto'. This happens by virtue of ComputeSize's calls to
ComputeAutoSize (which initializes the tentative bsize value to
NS_UNCONSTRAINEDSIZE) and to nsLayoutUtils::IsAutoBSize (which returns
"true" for eStyleUnit_Enumerated values and then makes us leave the
ComputeAutoSize result unperturbed).
I don't have a strong preference about blending with white vs. just doing alpha
0.5, so I kept doing what we were doing, since Blink and WebKit also apply the
blending to the text background, and I'm not sure that's particularly desirable.
MozReview-Commit-ID: AwYtAgdlcxj
Andreea Pavel
Alexis Beingessner
Jamie Nicol
Daniel Holbert
Ciure Andrei
Mats Palmgren
Dorel Luca
Botond Ballo
Cosmin Sabou
Bas Schouten
Jonathan Watt
Matt Woodrow
Brindusan Cristian
Daniel Zielas
Andrew McCreight
Emilio Cobos Álvarez
Sebastian Hengst
shindli
Tristan Bourvon
Nika Layzell
Noemi Erli
Boris Zbarsky
Nicholas Nethercote
Margareta Eliza Balazs
Ting-Yu Lin
Ryan VanderMeulen
Brad Werth
Hiroyuki Ikezoe
Jeff Muizelaar
Makoto Kato
Gurzau Raul
Jonathan Kew
Xidorn Quan