Note that this is an imperfect implementation, in that it doesn't exactly
match the sizing behavior of a truly empty `<select>` element. I've filed
followup bug 1562057 on that. However, the behavior that's implemented
here *does* successfully make us ignore a `<select>`'s contents for sizing
purposes, and it's much better than what we do currently (which is pretty
broken via inheriting a partial `contain:size` implementation from our
parent class, nsBlockFrame).
Differential Revision: https://phabricator.services.mozilla.com/D36253
--HG--
extra : moz-landing-system : lando
We move the check of important rule and animation level into
KeyframeEffect::ShouldBlockAsyncTransformAnimations(), and add a new warning
for it.
Note:
1. ShouldBlockAsyncTransformAnimations() only cares about transforms. And
for other compositor animation properties, we count on
HasEffectiveAnimationOfPropertySet() (in IsMatchForCompositor()).
2. If we check the important rules in both
EffectCompositor::HasAnimationsForCompositor() and
ActiveLayerTracker::IsTransformMaybeAnimated(), we may get the incorrect
animation warnings (i.e. TransformFrameInactive). In most cases, we
check these two functions together, so perhaps move the check of important
rules outside HasEffectiveAnimationOfPropertySet() is fine.
Besides, ActiveLayerTracker just tracks if there is a style change on this
property (or display item) on the active layers, so should be OK to not
check important rules in it.
So IsMatchForCompositor() should check all transform-like properties,
instead of each one, to get the correct result. (That's why we have to
refactor KeyframeEffect::GetPropertiesForCompositor() as well.)
Differential Revision: https://phabricator.services.mozilla.com/D34432
--HG--
extra : moz-landing-system : lando
Dragging the viewport scrollbar is accomplished by passing in a window
rather than an element.
Note that we can't just pass in the window's document.documentElement,
because coordinatesRelativeToScreen() would not give the correct result
for it. This is turn is because for a scrollable <div>, getBoundingClientRect()
returns the scroll frame's outer rect, but for the <html> element,
getBoundingClientRect() returns the root scroll frame's inner rect.
Differential Revision: https://phabricator.services.mozilla.com/D34258
--HG--
extra : moz-landing-system : lando
This patch makes `HTMLEditRules::ExpandSelectionForDeletion()` use `StaticRange`
instead of `nsRange` for comparing a point and a range (i.e., the DOM tree
won't be changed during it's alive). Unfortunately, we still have allocation
cost, but we can save the cost of registering and unregistering mutation
observer and computing common ancestor of the range.
Differential Revision: https://phabricator.services.mozilla.com/D35144
--HG--
extra : moz-landing-system : lando
The mozlog documents have been updated to reflect the addition of a `known_intermittent`
parameter in `test_status` and `test_end` included in the `StructuredLogger`, and across
multiple mozlog handlers and formatters.
As this was a major change, the version has been bumped to 4.2 for the next pypi release.
Web-platform-tests will eventually require this update in order for future patches related
to `known_intermittent` statuses to merge upstream.
Differential Revision: https://phabricator.services.mozilla.com/D36029
--HG--
extra : moz-landing-system : lando
Two less properties, now that we're not using nsStyleCoord for them we can do
this.
Unfortunately the grid resolved value code needs to serialize it still, so this
doesn't remove as much code.
Also fix the script since the generated file was renamed.
Differential Revision: https://phabricator.services.mozilla.com/D36349
* recordEvent for telemetry from the parent process when a generated password is filled via the context menu
* Extend existing mochitest-plain test to verify the expected telemetry events are recorded
* Add a filled flag to the generated password we store in the per-origin cache
- And use it to distinguish a first-fill from a subsequent re-use of each generated password
Differential Revision: https://phabricator.services.mozilla.com/D33364
--HG--
extra : moz-landing-system : lando
These changes are needed for consistently green runs with the new emulator with
"-gpu on".
Most changes are simple removal of fuzzy-if(geckoview) but I also needed to add
at least one new fuzzy-if.
In this configuration we can run reftests in just 2 chunks (20 minutes each on
opt/30 minutes on debug).
Differential Revision: https://phabricator.services.mozilla.com/D36258
--HG--
extra : moz-landing-system : lando
Updating to the new emulator avoids the network oddities observed in bug 1534732, but
there are a couple of tests that need to be skipped for a consistently green run.
Performance is improved, so we can run in fewer chunks. /opt is reliable, so moving
to tier 1; /debug is reliable except for existing perma-fail bug 1560736.
Differential Revision: https://phabricator.services.mozilla.com/D36260
--HG--
extra : moz-landing-system : lando
Upgrade to version 29.0.11 of the emulator and use '-gpu on' rather than
swiftshader_indirect, for most Android 7.0 tests. The upgrade appears to
finally resolve bug 1534732, improves reftest performance dramatically, and
allows us to reduce reftest "fuzz" for many tests.
marionette tests are excluded because they intermittently fail with network
errors (address in use); these tests are near end-of-life, so I don't think
this issue is worth investigating, but I'll file a follow-up bug to record
the issue.
web-platform tests are excluded because they are not very stable on the
existing emulator, making it difficult to compare results. I will file a
follow-up and work with :maja_zf to see if they can be upgraded soon.
Differential Revision: https://phabricator.services.mozilla.com/D36256
--HG--
extra : moz-landing-system : lando
This lets us avoid falling back to the generic implementations
unnecessarily.
Differential Revision: https://phabricator.services.mozilla.com/D36357
--HG--
extra : moz-landing-system : lando
* calculateNetworkId is now called before sending each ChangeEvent
* mNetworkId is truncated when no IPv4/IPv6 IDs could be computed
Differential Revision: https://phabricator.services.mozilla.com/D35780
--HG--
extra : moz-landing-system : lando
These tests fail because of the layer alignment issue on GeckoView (bug 1556685).
Differential Revision: https://phabricator.services.mozilla.com/D36167
--HG--
extra : moz-landing-system : lando