- `Array.map` becomes `Array.from`
- Array copying via `Array.slice` becomes `Array.from`.
- `Array.forEach` that did not rely on closures becomes `for`-`of` loops.
- Anything else: `Array.X` becomes `Array.prototype.X`.
Complex cases:
dom/bindings/test/TestInterfaceJS.js and
dom/bindings/test/test_exception_options_from_jsimplemented.html
use `Array.indexOf` to generate an error with a specific error message.
Switched to `Array.prototype.forEach` to generate the same error.
js/src/jit-test/tests/basic/exception-column-number.js
In this test `Array.indexOf()` is used to generate an error. Since the
exact message doesn't matter, I switched to `Array.from()`.
Intentionally not changed:
editor/libeditor/tests/browserscope/lib/richtext/richtext/js/range.js
Did not modify because this is 3rd-party code and the code uses
feature detection as a fall back when Array generics are not used.
testing/talos/talos/tests/dromaeo/lib/mootools.js
Did not modify because mootools adds the `Array.slice` method to the
`Array` object.
Not changed because they check the implementation of Array generics:
js/src/jit-test/tests/basic/arrayNatives.js
js/src/jit-test/tests/basic/bug563243.js
js/src/jit-test/tests/basic/bug618853.js
js/src/jit-test/tests/basic/bug830967.js
js/src/jit-test/tests/jaeger/recompile/bug656753.js
js/src/jit-test/tests/self-hosting/alternate-static-and-instance-array-extras.js
js/src/tests/non262/Array/generics.js
js/src/tests/non262/Array/regress-415540.js
js/src/tests/non262/extensions/regress-355497.js
js/src/tests/non262/extensions/typedarray-set-neutering.js
Depends on D27802
Differential Revision: https://phabricator.services.mozilla.com/D27803
--HG--
extra : moz-landing-system : lando
When setting large clipboard data, it may cause `TransactionTooLargeException`
in binder IPC. So we have to handle `RuntimeException`.
Differential Revision: https://phabricator.services.mozilla.com/D27466
--HG--
extra : moz-landing-system : lando
playbackState's default value is PlaybackState.STOPPED.
We can only enter PiP mode if media is playing but we don't save this playing
state.
If the user hasn't done anything to change this, like pause-play, when we check
the playbackState in BrowserApp to know to force fullscreen if still playing
we will not do so because the state is PlaybackState.STOPPED.
Differential Revision: https://phabricator.services.mozilla.com/D27935
--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
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