There are many bugs regarding our use of EffectSet::GetEffectSet(nsIFrame*)
because the intention of the caller is not clear. If it is called for the
primary frame of display:table content do we expect it to get the EffectSet
associated with the style frame or not? Generally it depends on if we are
looking for transform animations or not.
Rather than inspecting each call site and making it choose the appropriate frame
to use, this patch introduces a new method to EffectSet to get the appropriate
EffectSet based on the properties the caller is interested in.
This patch also uses this function in FindAnimationsForCompositor which in turns
fixes the glitching observed on Tumblr that arose since a number of places in
our display list code were passing the style frame to
EffectCompositor::HasAnimationsForCompositor.
Over the remainder of this patch series we will convert more callers of
EffectSet::GetEffectSet(nsIFrame*) to this new method before renaming
EffectSet::GetEffectSet to GetEffectSetForStyleFrame to make clear how the
method is intended to work.
Differential Revision: https://phabricator.services.mozilla.com/D23282
--HG--
extra : moz-landing-system : lando
It took me a long time to understand why
KeyframeEffect::HasEffectiveAnimationOfPropertySet behaved so differently to
KeyframeEffect::HasAnimationOfPropertySet. This patch attempts to clarify that
while making KeyframeEffect::HasEffectiveAnimationOnPropertySet a little more
generally useful. This will allow us to tidy up the various animation checks in
nsLayoutUtils later in this patch series.
Ultimately, however, we should make this check part of the regular compositor
animation vetting machinery in bug 1534884. That should remove a number of
inconsistencies such that we don't need the extended comments added in this
patch.
Differential Revision: https://phabricator.services.mozilla.com/D23281
--HG--
extra : moz-landing-system : lando
The trouble with utility functions that take an nsIFrame is it's not clear what
the caller's intention is. For example, with
nsLayoutUtils::HasCurrentTransition, is the caller asking for transitions on
that frame? Or animations on _both_ that frame and its corresponding
style/primary frame?
Probably the caller hasn't even thought about it and there are likely to be bugs
when display:table content is encountered.
Where practical it's much better to take an element/pseudo pair since it's clear
that the caller is concerned with all animations (or transitions in this case)
on the element regardless of how it is represented in the frame tree.
This patch updates nsLayoutUtils::HasCurrentTransition to take an element/pseudo
pair and moves it to mozilla::AnimationUtils at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D23280
--HG--
extra : moz-landing-system : lando
I was unable to create a failing reftest for this since this method is not
used when determining whether or not to create a stacking context.
However, I verified that for content with animated transforms and
will-change:transform on display:table content this change does cause us to
return true from the will-change check in this method when previously it would
not.
Differential Revision: https://phabricator.services.mozilla.com/D23279
--HG--
extra : moz-landing-system : lando
We test the transform-style of a frame in places like
KeyframeEffect::CanAnimateTransformOnCompositor but this will likely not work as
expected for display:table content since the transform-style will not be
inherited to the primary frame (and later in this patch series we will ensure
that we are dealing with the primary frame in
KeyframeEffect::CanAnimateTransformOnCompositor).
The individual transform properties are new but they should also be inherited so
that all the appropriate tests for "is this frame transformed?" produce the
correct result when these properties are applied.
Differential Revision: https://phabricator.services.mozilla.com/D23278
--HG--
extra : moz-landing-system : lando
Disable the following tests, with 1536211 serving as the tracking bug:
- test_header_Server_Timing.js (1530871)
- test_trr.js (1532395)
- test_esni_dns_fetch.js (1530752)
Differential Revision: https://phabricator.services.mozilla.com/D23922
--HG--
extra : moz-landing-system : lando
Disable tests as they fail constantly on xpcshell-8 on windows10-aarch64.
Bug 1536221 is filed for investigating why the crashreporter tests still fail.
Differential Revision: https://phabricator.services.mozilla.com/D23940
--HG--
extra : moz-landing-system : lando
In the mochitest harness, is_fennec is populated by examining harness options, and
is_emulator and android_version are populated by examining the device via mozdevice.
The per-test code doesn't have those options and the emulator may not be available
yet, so I've opted for populated those fields from mozharness configuration. In
practice, we only run Android TV on Android 4.3, where is_fennec=True, is_emulator=True,
and android_version=18. I'd like to run TV on Android 7.0/geckoview eventually,
where is_fennec=False, is_emulator=True, and android_version=24.
Since I was here, I also removed 'stylo' from the per-test mozinfo, since that field
is obsolete now.
Differential Revision: https://phabricator.services.mozilla.com/D23595
--HG--
extra : moz-landing-system : lando
This patch also base64-decodes the API inputs before storing in the DB in
anticipation of being able to pass binary data directly (bug 1535752).
Differential Revision: https://phabricator.services.mozilla.com/D23430
--HG--
extra : moz-landing-system : lando
A patch of mine starts calling nsLookAndFeel from xpcshell tests, which makes
gtk crash eventually.
Differential Revision: https://phabricator.services.mozilla.com/D23759
--HG--
extra : moz-landing-system : lando
The wpt reftest window was mixing up width and height for initial
opening, meaining that it would be the wrong shape for non-square
configurations. This caused us to go down a path where we weren't
passing DRAWWINDOW_USE_WIDGET_LAYERS which turns out to be broken and
result in frequent blank screenshots.
Fix the window dimensions and make the broken path an error instead.
Differential Revision: https://phabricator.services.mozilla.com/D23323
Automatic update from web-platform-tests
[wptrunner] Reset internal state during "rerun" (#15488)
The "reftest" implementation uses an internal cache for screenshots as
an optimization for running similar tests. That optimization is
inappropriate for the CLI's "rerun" feature since in that context,
repeatedly running the same tests is an explicit goal.
Introduce a generic "reset" message that is emitted by the
TestRunnerManager during "rerun", and extend the RefTestExecutor to
handle this message by emptying its internal cache.
--
wpt-commits: f650eb264890a42067f0703fa1e7350c4d8f31d2
wpt-pr: 15488
Automatic update from web-platform-tests
[wptrunner] Do not use undefined method
The Selenium wire protocol does not define a "set window rect" method
[1]. Implement the desired behavior by composing the "set window
position" and "set window size" methods.
[1] https://github.com/SeleniumHQ/selenium/wiki/JsonWireProtocol
--
wpt-commits: 823542ced8f584e121f6196702e1a7e5958530ed
wpt-pr: 15556
Automatic update from web-platform-tests
custom-elements: Update CustomElementRegistry.html for 'disabledFeatures'.
This change is for https://github.com/whatwg/html/pull/4324, and
a follow-up of https://github.com/web-platform-tests/wpt/pull/15123
Bug: crbug.com/905922
Change-Id: I3eceb5d21ab555c23ed877ded17d359fe004e2aa
Reviewed-on: https://chromium-review.googlesource.com/c/1482361
Auto-Submit: Kent Tamura <tkent@chromium.org>
Reviewed-by: Hayato Ito <hayato@chromium.org>
Commit-Queue: Kent Tamura <tkent@chromium.org>
Cr-Commit-Position: refs/heads/master@{#635380}
--
wpt-commits: 1aa5413b0c0a03d3c93e07d18bf8cc78e19ca611
wpt-pr: 15516
Automatic update from web-platform-tests
[LayoutNG] Fix 3 cases of break opportunities after nowrap
This patch fixes lines to break in the following conditions:
1. When wrappable elements appear inside of nowrap elements.
2. When wrappable spaces after nowrap appear inside of nowrap
elements.
3. When non-space break opportunities appear after nowrap.
fast/text/whitespace/018.html improves but still doesn't pass.
It doesn't pass in Edge/Gecko, and at least some of what it
expects look questionable. Further investigation is deferred
to future CLs.
Bug: 920177
Change-Id: Ieba4d446b818120f423b87a7f4a44b3c63a9d995
Reviewed-on: https://chromium-review.googlesource.com/c/1477629
Commit-Queue: Koji Ishii <kojii@chromium.org>
Reviewed-by: Xiaocheng Hu <xiaochengh@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Cr-Commit-Position: refs/heads/master@{#635180}
--
wpt-commits: 67e1c4c4f8a43d17bcf89b6f5a197d21765f4b46
wpt-pr: 15509
Automatic update from web-platform-tests
[css-flexbox] Shrink-to-fit sizing needs to take margins into account
Originally added in https://crrev.com/c/1327746
Also fixes a typo in one of the tests from that patch.
R=mstensho@chromium.org
Bug: 934936
Change-Id: Ib079171549853a21d5bcdd05dabb461c4a1e492c
Reviewed-on: https://chromium-review.googlesource.com/c/1483946
Auto-Submit: Christian Biesinger <cbiesinger@chromium.org>
Commit-Queue: Christian Biesinger <cbiesinger@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#635176}
--
wpt-commits: 8d457c05eb33ab4b6a7549696fe1b94b5e4b7054
wpt-pr: 15552
