This provides a flipped data structure based on the provided inheritedAttributes,
which looks like:
Object<selector, attrs_to_inherit_comma_separated>
To one that looks like:
Object<attr, Array<Array<selector, attr_to_inherit>>
This should improve performance because:
1) We only fetch element at connectedCallback that actually will have attributes inherited.
2) When an attribute changes we can quickly inherit only that one.
Differential Revision: https://phabricator.services.mozilla.com/D27801
--HG--
extra : moz-landing-system : lando
The "SwapDocShells" event should be deferred until "EndSwapDocShells".
Otherwise the event MessageManagerProxy may swap the event listeners
twice, and end up having the listeners on the incorrect message manager.
Differential Revision: https://phabricator.services.mozilla.com/D27295
--HG--
extra : moz-landing-system : lando
We are starting to spin off more and more "variants" of test suites. These are
usually just duplicates of our pre-existing tasks, except with an additional
pref set.
Currently there are two variants (serviceworker-e10s and socketprocess-e10s),
but a third will be added soon (fission). This change ensures we handle these
types of requests in a consistent and well defined manner. It also splits tasks
in a loop, so we don't accidentally risk combinatorial explosion.
Variants should typically be reserved for very large changes that will impact
the entire codebase (think e10s).
Differential Revision: https://phabricator.services.mozilla.com/D28061
--HG--
extra : moz-landing-system : lando
For bug 726781, the Windows installer was patched to begin creating a special
registry key when installing an ESR build, to provide a convenient indication
that the product that's installed is an ESR version of the product.
This key contains only the version number of the application being installed;
it is separate from the keys that are always created, for all types of
builds, and that contain the installation path, etc.
During an uninstall or a paveover install, the registry is cleaned by looking
for any keys which contain the path to the application being uninstalled and
removing those; the RegCleanMain function handles this, and for non-ESR builds
it works well. However, there is nothing that tries to remove or update the
special ESR key when an ESR build is being uninstalled or paved over with a
non-ESR build. This patch adds that code to RegCleanMain.
Differential Revision: https://phabricator.services.mozilla.com/D26625
--HG--
extra : moz-landing-system : lando
We don't want spurious net connections, so we should mock the result.
In addition, we need to mock it to a specific non-North-American region to
ensure we don't cause an extra change to browser.search.region which may split
the subsession in the middle of our tests.
Differential Revision: https://phabricator.services.mozilla.com/D28059
--HG--
extra : moz-landing-system : lando
Add entitlement files for Hardened Runtime configuration to be used by Release Engineering for official builds and try builds and developers for local builds. These entitlement files are input to the codesign command.
Hardened Runtime and codesigning is not yet enabled for local builds or try builds so for now these files will only be used by Release Engineering.
production.entitlements.xml is intended to be used for official channel builds that will be codesigned, notarized, and shipped to users.
developer.entitlements.xml is intended to be used for developer and try builds that will be codesigned, but not notarized or shipped to users. The developer file enables debugging which is not compatible with notarization, but is otherwise the same as the production file.
codesign.bash is a stop-gap script to allow developers who setup Apple Developer ID certificates to codesign Nightly themselves and enabled Hardened Runtime.
Differential Revision: https://phabricator.services.mozilla.com/D27396
--HG--
extra : moz-landing-system : lando
`caskroom/versions` was replaced with `homebrew/cask-versions` in 2018.
Tap `caskroom/versions` instead of the old one.
If you have two taps, remove the old one using:
brew untap caskroom/versions
Differential Revision: https://phabricator.services.mozilla.com/D27839
--HG--
extra : moz-landing-system : lando
Pausing isn't implemented for BITS and this UI will be removed entirely in the future.
Differential Revision: https://phabricator.services.mozilla.com/D27847
--HG--
extra : moz-landing-system : lando
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
