We only want to append the action TASK_ID to the task dependencies when the taskGroupId doesn't match, otherwise we hit dup dependency errors.
Differential Revision: https://phabricator.services.mozilla.com/D27994
--HG--
extra : moz-landing-system : lando
For XULTreeAccessible, the ChildCount() is not only the mChildren, so check mChildren directly to make sure we stay within bounds
Differential Revision: https://phabricator.services.mozilla.com/D27553
--HG--
extra : moz-landing-system : lando
Depends on D27675
The target of the iframe load event is the content document when running in frame with type=chrome.
When running in frame with type=content, the target will be the iframe element itself.
Stop relying on event.target so that the Sidebar can work in both cases
Differential Revision: https://phabricator.services.mozilla.com/D27677
--HG--
extra : moz-landing-system : lando
Some classes in DevTools will not have an easy way to get access to the toolbox.
However they might still want to use the topmost chrome window.
Extract the logic from toolbox.js to a shared helper.
Differential Revision: https://phabricator.services.mozilla.com/D27672
--HG--
extra : moz-landing-system : lando
Shutting down the taskqueue early prevents the decoder's tasks to be queued.
A TaskQueue no longer requires to be explicitly shutdown it will shutdown when ref counter drops to zero.
Differential Revision: https://phabricator.services.mozilla.com/D26929
--HG--
extra : moz-landing-system : lando
It's a bit useless, only has one implementation. Call into the shell directly
instead.
Differential Revision: https://phabricator.services.mozilla.com/D27910
--HG--
extra : moz-landing-system : lando
See the previous patch in this series for a detailed explanation of why this is
necessary.
The test included in this patch is from some work I am doing to rewrite the CSS
transitions web-platform-tests. As a result, it includes more than is strictly
related to this issue addressed by this bug. Without the code changes in this
patch the fourth test onwards, "Transitions are canceled when an element is
removed from the document", will timeout waiting for the transitioncancel event.
Differential Revision: https://phabricator.services.mozilla.com/D28022
--HG--
extra : moz-landing-system : lando
Currently we avoid posting animation restyles when unbinding an element by
removing the element from the document before deleting its animation
collections. As a result, when canceled animations go to post a restyle, they
can't find a pres context and give up posting a restyle.
However, this is problematic for two reasons:
* It means we can't remove such canceled animations from the
PendingAnimationTracker if they are present there (i.e. it regresses the fix
from bug 1223445).
* It means we can't post cancel events for such animations/transitions since we
can't lookup the appropriate AnimationEventDispatcher.
In the next patch in this series we will change that order to fix the above
problems but before we do that, we need to introduce another mechanism to make
sure that we don't post restyles when unbinding an element or else we will
regress bug 1396041.
This patch does that by introducing a flag which causes us to not post restyles
when we are doing DOM surgery. For all other cases we actually _do_ need to post
restyles in order to update the style correctly.
Without this patch, layout/style/crashtests/1396041.html would fail after
applying the next patch in this series.
Differential Revision: https://phabricator.services.mozilla.com/D28021
--HG--
extra : moz-landing-system : lando
Animation::Cancel calls UpdateTiming() which in turns runs the procedure to
update the finished state. However, the spec[1] doesn't require that.
Furthermore, calling UpdateTiming here hides the fact that we end up triggering
a restyle.
It would be better to move the parts of UpdateTiming we require into Cancel
itself so that we align better with the spec and to make it a bit more clear
what side-effects of UpdateTiming we actually rely on.
[1] https://drafts.csswg.org/web-animations-1/#cancel-an-animation
Differential Revision: https://phabricator.services.mozilla.com/D28020
--HG--
extra : moz-landing-system : lando
CancelNoUpdate actually can and does trigger restyles via its call to
KeyframeEffect::NotifyAnimationTimingUpdated so at very least its name is wrong.
Furthermore, we actually want canceling to trigger restyles in most cases since
when an animation is canceled we need to trigger a subsequent restyle to apply
the (no-longer-animated) result.
This wasn't necessary when CancelNoUpdate was first introduced but since then we
have introduced the Servo style engine where we use a separate traversal to
apply the result from creating/deleting/modifying animations.
This change will mean that we now trigger a "layer" restyle when canceling an
animation when we previously didn't. That, however, seems more correct if
anything.
This patch also makes CancelFromStyle no longer virtual since it doesn't seem
necessary anymore (perhaps because we now point to the concrete type:
CSSAnimation/CSSTransition from nsAnimationManager/nsTransitionManager whereas
previously we didn't).
Differential Revision: https://phabricator.services.mozilla.com/D28019
--HG--
extra : moz-landing-system : lando
aBuilder->InInvalidSubtree() tracks the modified state. Save the state
during construction of nsDisplayItem and use in ProcessItemFromNewList.
Depends on D24462
Differential Revision: https://phabricator.services.mozilla.com/D26138
--HG--
extra : moz-landing-system : lando
To avoid expensive virtual dispatch in PreProcessDisplayList().
Depends on D24460
Differential Revision: https://phabricator.services.mozilla.com/D26136
--HG--
extra : moz-landing-system : lando
Also move to first cache-line (64-bytes) of nsDisplayItem to improve D-cache hit
when accessing mFrame, mItemFlags, etc.
Differential Revision: https://phabricator.services.mozilla.com/D26134
--HG--
extra : moz-landing-system : lando
The script->incWarmUpCounter() calls are moved out of the CanEnterBaseline functions
and into the callers. This makes it easier to reason about and prevents incrementing it
multiple times for the different tiers/flags.
baselineWarmUpThreshold should be renamed to baseline{Jit,Compiler}WarmUpThreshold,
but that will happen later with other prefs-related changes.
Differential Revision: https://phabricator.services.mozilla.com/D27321
--HG--
extra : moz-landing-system : lando
Next patch will call CanEnterBaselineJIT also for BaselineInterpreter => BaselineJIT OSR.
Differential Revision: https://phabricator.services.mozilla.com/D27320
--HG--
extra : moz-landing-system : lando
This prevents some false positive rooting hazards with later patches in the stack.
It would be pretty bad if this callback could GC (browser-only, in the middle of
frame iteration).
Differential Revision: https://phabricator.services.mozilla.com/D28039
--HG--
extra : moz-landing-system : lando
On startup we record the size and modified time of the profile lists. If
changed we refuse to flush any new changes to disk. Also adds a getter to check
if they've changed so the UI can do something sensible.
All attempts to flush are now checked for success. In some cases in early
startup the failure mode isn't great, we just quit startup. The assumption
though is that it's extremely unlikely that the files will have changed on disk
in the time between when they are read and when profile selection occurs, likely
less than a second later.
The profile reset flow is changed to only delete the old profile and flush once
all the migration has completed, so if something fails the user gets back to
their old profile.
In testing I ended up having to fix bug 1522584 so background file deletions on
a background thread are safer.
I haven't implemented any UI tests right now since making modifications to the
profiles means modifying the actual user's profiles which I'm not keen to do.
See bug 1539868.
Differential Revision: https://phabricator.services.mozilla.com/D25278
--HG--
extra : moz-landing-system : lando
Moves the mask to the url and title elements, uses a flex layout to ensure
elements properly overflow, and fixes alignments and paddings because the new
layout would be more compact. rows are slightly taller than before, but they were
smaller than the legacy bar, so in the end we should be good.
Differential Revision: https://phabricator.services.mozilla.com/D27868
--HG--
extra : moz-landing-system : lando
Changes:
- most tests are skipped using `moz.build` configuration file.
- `MultiWriterQueue` had to be skipped with `define` clauses in the test file due to build bustages when its `moz.build` file was used.
Differential Revision: https://phabricator.services.mozilla.com/D27944
--HG--
extra : moz-landing-system : lando
There's a readonly shorcut, which prevents us altogether to register the
mutation observer which would notify us of that attribute changing.
Move the readonly check further down to StartControllingInput, so that we
register the mutation observer properly.
Differential Revision: https://phabricator.services.mozilla.com/D27883
--HG--
extra : moz-landing-system : lando
Sometimes, we use aria-activedescendant targeting something which isn't actually a descendant.
This is technically a spec violation, but it's a useful hack which makes certain things much easier.
For example, we use this for "fake focus" for multi select browser tabs and Quantumbar autocomplete suggestions.
This already worked previously; the accessible received a focus event and the focused state.
However, it did *not* receive the focusable state.
This is because the code which applies the focusable state for potential active descendants only works for descendants.
It really doesn't make sense for something to be focused when it isn't focusable.
In fact, this is an a11y test failure when it occurs.
So, if the active item has the focused state, ensure we expose the focusable state too.
Differential Revision: https://phabricator.services.mozilla.com/D27021
--HG--
extra : moz-landing-system : lando
It just does wasted work. The new setup is also much more similar to the one
used for element states.
Differential Revision: https://phabricator.services.mozilla.com/D27905
--HG--
extra : moz-landing-system : lando
this change adds support for parallel gcp builds for the following android build configurations:
- android-api-16
- opt
- debug
- android-x86
- opt
- android-x86_64
- opt
- debug
- android-aarch64
- opt
- debug
implementation notes:
- this patch mostly mirrors the equivalent windows-on-gcp patch at: https://phabricator.services.mozilla.com/D24865
- gcp builds are triggered with a treeherder tier 3 flag so that they are only displayed in the treeherder ui when the user has a tier 3 flag set.
- gcp builds use a th build symbol of "Bg" to make them easy to differentiate from ec2 builds in the treeherder ui.
- gcp builds use a perfherder "gcp" flag to make them easier to differentiate from ec2 builds in the perfherder ui.
Differential Revision: https://phabricator.services.mozilla.com/D26584
--HG--
extra : moz-landing-system : lando
Brian Grinstead
Aki Sasaki
Razvan Maries
Magnus Melin
Julian Descottes
Christian Holler
Alex Chronopoulos
Emilio Cobos Álvarez
Daosheng Mu
Brian Birtles
Henrik Skupin
Ionut Goldan
Dan Glastonbury
Tim D. Smith
Rob Wood
Jan de Mooij
Dave Townsend
Paul Bone
Marco Bonardo
Dorel Luca
Daisuke Akatsuka
Ehsan Akhgari
Edwin Gao
James Teh
Rob Thijssen