This lets us restrict the size of the mask surface that we allocate
to the destination tile size. This gives a large performance
improvement.
It also includes some miscelanous fixes to the CreateClippedDrawTarget
code path.
Differential Revision: https://phabricator.services.mozilla.com/D21750
DTO = DrawTargetOffset = (-Origin.x, -Origin.y)
CTM = CurrentTransform
MASKT = MaskTransform = Inv(CurrentTransform)
MASKO = MaskOffset = (GetRect().x, GetRect().y)
The transform to device space is:
MASKT * CTM * DTO
Currently we do:
MASKT = MASKT * MASKO
Which gives us MASKT * MASKO * CTM * DTO. This works fine if there's no scale but
will not properly cancel out if there is.
I believe we want:
MASKO * MASKT * CTM * DTO
To get this we need to preTranslate instead of postTranslate.
Differential Revision: https://phabricator.services.mozilla.com/D21604
Since bug 1524480 we set the NS_FRAME_MAY_BE_TRANSFORMED frame bit when needed
in RestyleManager::ProcessRestyledFrames so that it is now redundant to also set
it from KeyframeEffect.
Furthermore, setting frame bits from KeyframeEffect is a little fragile since it
depends on the life cycle of the KeyframeEffect which is independent of the
nsFrame. If we can avoid doing that, we probably should.
Differential Revision: https://phabricator.services.mozilla.com/D21885
--HG--
extra : moz-landing-system : lando
As with the previous patch in this series, we need to pay particular attention
to how we handle display:table content when detecting animations on a element.
Please see the extended description in that patch for an explanation of
different frame types involved.
As with transforms, our handling of opacity is also inconsistent. In
particular, we fail to return true from nsIFrame::HasOpacityInternal for
display:table content with opacity animations applied due to the conflicting
requirements for a primary frame and having opacity animations (which are stored
on the style frame).
Unlike transforms, however, we do not inherit the opacity to the table wrapper.
Instead we leave it on the inner table frame. As a result, we should not check
for a primary frame, but instead we should check for the style frame for the
primary frame.
This patch adjusts this handling to check instead for the appropriate style
frame as opposed to requiring a primary frame. It includes a reftest that fails
without the code changes in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D21884
--HG--
extra : moz-landing-system : lando
For display:table content we generate two frames: a table wrapper frame and an
inner table frame. The styles are applied to the inner frame (referred to as the
style frame), whilst the wrapper frame is the primary frame for the content.
However, in order to make tables with transforms behave as a container for
abspos/fixed-pos content as required by the spec, we apply the transform to the
wrapper frame (bug 722777) by inheriting the transform from inner to wrapper and
then ignoring the transform on the inner frame (bug 722777 and bug 816458).
When handling animations on table elements we need to be careful of this
distinction. in particular, css animations[1] and web animations[2] require that
when we have an unfinished transform animation targetting an element, the
element acts as if it had `will-change: transform` applied and therefore
generates a stacking context. As a result we need to accurately detect when
a frame should be considered as having transform animations applied to it or not
for the purpose of creating a stacking context.
Previously our handling of display:table content was quite inconsistent and
contradictory. For example, `nsIFrame::HasAnimationOfTransform` would check for
a primary frame AND for animations on that frame, despite the fact that we only
ever store animations on the style frame. As a result it could never return true
for either a table wrapper or inner table frame.
This patch attempts to make this handling at least a little more consistent,
producing the following result:
Outer table frame (primary frame):
nsIFrame::IsTransformed → true
nsIFrame::IsCSSTransformed → true
nsIFrame::HasAnimationOfTransform → true
nsLayoutUtils::HasAnimationOfProperty(frame, eCSSProperty_transform) → false
Inner table frame (style frame):
nsIFrame::IsTransformed → false
nsIFrame::IsCSSTransformed → false
nsIFrame::HasAnimationOfTransform → false
nsLayoutUtils::HasAnimationOfProperty(frame, eCSSProperty_transform) → true
We maintain that the NS_FRAME_MAY_BE_TRANSFORMED bit is only set on the primary
frame whilst the mMayHaveTransformAnimation flag is only set on the style frame.
Note that we don't simply always put everything on the primary frame because for
other property types (e.g. opacity) the default setup of putting all styles and
animations on the style frame is simpler and correct. So far it is only
transforms that require special handling to apply the effect to the wrapper
frame.
This patch adds a reftest that fails without the code changes included in this
patch.
[1] https://drafts.csswg.org/css-animations/#animations
[2] https://drafts.csswg.org/web-animations-1/#side-effects-section
Differential Revision: https://phabricator.services.mozilla.com/D21883
--HG--
extra : moz-landing-system : lando
With splitting `HandleEvent()` a lot, it becomes more difficult to keep
managing each set of calling `PushCurrentEventInfo()` and
`PopCurrentEventInfo()`. So, `EventHandler` should have a helper class
to push and pop current event info into/from the stack.
Differential Revision: https://phabricator.services.mozilla.com/D21198
--HG--
extra : moz-landing-system : lando
The calculation of aOverflow rect for a placeholder contained in a transformed
stacking context didn't take the transform into account, leading to an incorrect
rect which artificially inflated the calculated rebuild region.
Differential Revision: https://phabricator.services.mozilla.com/D21168
--HG--
extra : moz-landing-system : lando
This patch avoids a potential division by 0 (one that's unlikely to be
triggered by real content), for correctness and robustness.
This patch isn't really changing the logic, because the newly-guarded code is
already guarded by a "length < sum" check, and "length" is expected to be
nonnegative [1], which means "sum" would already have been nonzero in cases
where the existing strict less-than comparison returned true.
[1] One special case where we can have negative `length` values here:
if this is an outline with an `outline-offset` that is sufficiently negative
to entirely cancel out the outlined element's border-box size, then that can
produce a negative `length` (i.e. the outline box will have a negative size,
conceptually). In that scenario, we were previously dividing by 0 here and
working with bogus huge/infinite negative values as a result, but we should
not do that.
Depends on D21578
Differential Revision: https://phabricator.services.mozilla.com/D21579
--HG--
extra : moz-landing-system : lando
This patch doesn't change any logic/behavior -- it's just adding braces for clarity.
Differential Revision: https://phabricator.services.mozilla.com/D21578
--HG--
extra : moz-landing-system : lando
The way we control APZ zooming in WebRender is by inserting an animation
property placeholder on a WR stacking context, and then having APZ
update the animation transform value with the proper matrix at composite
time.
Previously, the stacking context being used was the rootmost
stacking context in the content process. However this doesn't work for
zoomable content in the UI process (e.g. about:support), and after
recent changes, also wraps display items that should not be affected by
zoom (e.g. scrollbars or the background color item).
This patch moves the animation property placeholder so that it
corresponds to the newly added nsDisplayAsyncZoom display item, which
corrects both of the above problems and is conceptually in line with the
desired behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D21795
--HG--
extra : moz-landing-system : lando
This also adopts the resolution from [1] while at it, making letter-spacing
compute to a length, serializing 0 to normal rather than keeping normal in the
computed value, which matches every other engine.
This removes the SMIL tests for percentages from letter-spacing since
letter-spacing does in fact not support percentages, so they were passing just
by chance.
[1]: https://github.com/w3c/csswg-drafts/issues/1484
Differential Revision: https://phabricator.services.mozilla.com/D21850
--HG--
extra : moz-landing-system : lando
The existing ANR and tombstone checks in remoteautomation are used
by mochitests and reftests but are awkward for other harnesses like cppunit
that do not use remoteautomation...and easily missed. This patch moves that
code to the mozharness AndroidMixin, treating ANRs and tombstones like the
logcat: Make sure any old logs are deleted when the mozharness script starts,
then move any logs found at the end of the run to the upload directory.
https://treeherder.mozilla.org/#/jobs?repo=try&tier=1%2C2%2C3&revision=f3de1e9836da2b0c9232f5d92c751b979459e19b
demonstrates tombstone artifacts for the Android 7.0 cppunit tests.
Differential Revision: https://phabricator.services.mozilla.com/D21774
--HG--
extra : moz-landing-system : lando
Most remaining code in `PresShell::EventHandler::HandleEvent()` is what computes
event target of the event which should be handled on focused content. This
patch moves the part to the new method.
Additionally, moves `nsIPresShell::gKeyDownTarget` to
`EventHandler::sLastKeyDownEventTargetElement` and make it use `StaticRefPtr`.
Finally, for using `Element*` instead of `nsIContent*`, changes the result type
of `Document::GetUnfocusedKeyEventTarget()` to `Element*`.
Differential Revision: https://phabricator.services.mozilla.com/D21195
--HG--
extra : moz-landing-system : lando
Although debug build of Android/arm runs on emulator, test_parse_rule.html
sometimes runs over 5 min. So we should extend timeout value for this.
Differential Revision: https://phabricator.services.mozilla.com/D21663
--HG--
extra : moz-landing-system : lando
nsIconChannel (for moz-icon:// images) is unsound, see bug 1438939.
nsMenuPopupFrame::Init is also unsound on mac, looks like...
I'll try to get them fixed on trunk, but it's not worth crashing release for
this IMO, given it's pre-existing. The assert in PresShell::~PresShell hopefully
avoids exploitable issues.
Differential Revision: https://phabricator.services.mozilla.com/D20945
--HG--
extra : moz-landing-system : lando
urlExtraReferrer could be null, we should check before dereference. Otherwise
it will cause crash when webrender is enabled by gfx.webrender.enabled=true
and gfx.webrender.all=true,
Differential Revision: https://phabricator.services.mozilla.com/D20805
--HG--
extra : moz-landing-system : lando
When the event is not handled with coordinates and there is no frame for
`mPresShell`, `PresShell::EventHandler::HandleEvent()` handles the events
simpler than the case there is a frame. Therefore, this patch moves the
`else` block of `if (aFrame)` and reduce the indent of `if (aFrame)` case.
Differential Revision: https://phabricator.services.mozilla.com/D21194
--HG--
extra : moz-landing-system : lando
As it turns out we need this to avoid losing precision both during painting and
during serialization.
This patch also changes to serialize `context-value` if it's the computed value.
I could keep the previous behavior, but it makes no sense to serialize the
initial value. We're the only ones to support this value anyway, and I couldn't
find a definition or spec for this.
Also update tests and expectations for:
* New unexpected passes.
* Always serializing the unit in getComputedStyle.
* Calc and interpolation support.
Chrome also always serializes the unit in getComputedStyle, so I'm pretty sure
this is compatible with them. Chrome is inconsistent and keeps numbers in
specified style, but that's inconsistent with itself and with other quirky
lengths, so I updated the tests instead.
Differential Revision: https://phabricator.services.mozilla.com/D21819
Instead of storing them as LengthPercentage | Number, always store as
LengthPercentage, and use the unitless length quirk to parse numbers instead.
Further cleanups to use the rust representation can happen as a followup, which
will also get rid of the boolean argument (since we can poke at the rust length
itself). That's why I didn't bother to convert it to an enum class yet.
Differential Revision: https://phabricator.services.mozilla.com/D21804
Now, the block in HandleEvent(), which handles event using coordinates is
less than 200 lines. Perhaps, this is good amount to be split to a method.
This patch just moves the block to a new method.
Differential Revision: https://phabricator.services.mozilla.com/D21193
--HG--
extra : moz-landing-system : lando
After dispatching pointer events, `PresShell::EventHandler::HandleEvent()`
updates event target only when the event is a touch event. We should do it in
a new method of `EventTargetData`.
Although I don't know why this is done in
`PresShell::EventHandler::DispatchPrecedingPointerEvent()`.
Differential Revision: https://phabricator.services.mozilla.com/D21192
--HG--
extra : moz-landing-system : lando
We restrict the argument (i.e. `nsCSSPropertyIDSet`) of some functions is
the subset of other property set (e.g. transform-like properties), so
add this function for better readability.
Depends on D19629
Differential Revision: https://phabricator.services.mozilla.com/D21598
--HG--
extra : moz-landing-system : lando
Transform display item may have multiple properties, so it's better to
use display item type as the input.
Also, factor some code out of AddAnimationsForProperty, so we can easier
to extend this for multiple properties.
We will pass a list of layers::Animation to the compositor thread. In
this list, the animations belonging to the same property are grouped together,
so we can easily separate the animations by property and sample the animations
for each property on the compositor thread. (Will do this in Bug 1425837.)
Depends on D19628
Differential Revision: https://phabricator.services.mozilla.com/D19629
--HG--
extra : moz-landing-system : lando
We use DisplayItemType as the input of HasAnimationsForCompositor, and
nsCSSPropertyIDSet as the input of GetAnimationsForCompositor.
The caller of HasAnimationsForCompositor just wants to check if there is
any compositor animation for a display item, so we can replace it by the
display item, and get the properties from this display item.
However, the caller of GetAnimationsForCompositor may use a subset of
transform-like properties for getting scale factors, or use all the
transform-like properties for sending all transform animations to the
compositor thread.
Depends on D19630
Differential Revision: https://phabricator.services.mozilla.com/D19628
--HG--
extra : moz-landing-system : lando
FrameLayerBuilder needs to clear this flag by DisplayItemType, so we add
a new function for it.
Differential Revision: https://phabricator.services.mozilla.com/D19630
--HG--
extra : moz-landing-system : lando
Now, we can move the block dispatching preceding pointer event to separated
method. Then, we can hide the complicated retarget process after dispatching
a pointer event from HandleEvent().
Differential Revision: https://phabricator.services.mozilla.com/D21191
--HG--
extra : moz-landing-system : lando
shindli
Daniel Holbert
Neil Deakin
Bogdan Tara
Matt Woodrow
Ciure Andrei
Jeff Muizelaar
Hiroyuki Ikezoe
Brian Birtles
Masayuki Nakano
Dan Glastonbury
Kartikaya Gupta
Emilio Cobos Álvarez
Geoff Brown
Tim Nguyen
Sam Sneddon
Miko Mynttinen
Makoto Kato
violet
Razvan Maries
Daniel Varga
Dorel Luca
Boris Chiou
Joel Maher
Botond Ballo
Gurzau Raul