- `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 a remote type mismatch is found for a subframe, this patch checks if
fission is enabled for that window. If it is, it triggers a process switch,
continuing the load in a new process.
With this patch, subframes will only change process when navigating to a HTML
subframe, and not when navigating to a non-HTML subframe. That will be fixed in
a follow-up. This patch also does not change the remote type selection logic,
so only very limited types of remote iframes are supported.
Differential Revision: https://phabricator.services.mozilla.com/D27513
--HG--
extra : moz-landing-system : lando
We need to handle autofilling the first result separately from autofilling results in general (which happens in UrlbarInput.setValueFromResult), so add a new UrlbarInput.autofillFirstResult method. The controller calls it instead of setValueFromResult. I ported the logic from nsAutoCompleteController, as described in the bug.
Other changes are related to the new test for this.
As part of this work, I was interested in learning how awesomebar handles browser_autoFill_typed.js, so I added it to the legacy tests, with a small tweak in the test for awesomebar.
Differential Revision: https://phabricator.services.mozilla.com/D26852
--HG--
extra : moz-landing-system : lando
Just set the RemoteType in the options object argument, instead of
doubling up the information.
Differential Revision: https://phabricator.services.mozilla.com/D23250
--HG--
extra : moz-landing-system : lando
This will fix the behavior, I think it might still be worth deliberating
over whether we want to consider non-default userContextId's when tracking
the number of pinned tabs or not. This will be visually correct - the
number of pinned tabs won't change, so things won't be moving around in
the tab bar, but we will throw away the preopened tab once we get further
down in SessionStore.jsm, which is less than ideal.
Differential Revision: https://phabricator.services.mozilla.com/D22195
--HG--
extra : moz-landing-system : lando
This adds test which reproduce the failure as well as the fix. Essentially,
if we hit the edited case in SessionStore with `tab` equal to `tabbrowser.tabs[t]`,
we remove the tab and then try to pin it, which obviously blows up.
Note: the additional method in SessionStore.jsm was largely to get around
complexity requirements inside restoreWindow. Cleaner solutions welcome.
Differential Revision: https://phabricator.services.mozilla.com/D21383
--HG--
extra : moz-landing-system : lando
When we open firefox with pinned tabs, we first paint a window with
one tab open, and then that tab gets displaced after the pinned tabs
come in. This aims to ensure that our first paint contains the
pinned tab, so that we don't have tabs moving around after first
paint.
MozReview-Commit-ID: GC1y6NlgLTd
Differential Revision: https://phabricator.services.mozilla.com/D18742
--HG--
extra : moz-landing-system : lando
The test uses some custom code to wait for the new window, probably just
because the test is old. The fix is to use the BrowserUtils method instead.
Differential Revision: https://phabricator.services.mozilla.com/D18478
--HG--
extra : moz-landing-system : lando
This removes the need to go through the browser-to-tab mapping when discarding
a tab and simplifies the relevant code. Besides being renamed discardBrowser()
was also split so that one can check if a tab can be discarded prior to trying
it.
Differential Revision: https://phabricator.services.mozilla.com/D20475
--HG--
extra : moz-landing-system : lando
When we open firefox with pinned tabs, we first paint a window with
one tab open, and then that tab gets displaced after the pinned tabs
come in. This aims to ensure that our first paint contains the
pinned tab, so that we don't have tabs moving around after first
paint.
MozReview-Commit-ID: GC1y6NlgLTd
Differential Revision: https://phabricator.services.mozilla.com/D18742
--HG--
extra : moz-landing-system : lando
Current window state in the sessionstore system includes `sizeMode` which can be "normal", "minimized", "maximized". However, the OS also remembers whether the window was "normal" or "maximized" before minimization to restore it appropriately. With this fix, sessionstore does likewise.
Differential Revision: https://phabricator.services.mozilla.com/D13234
--HG--
extra : moz-landing-system : lando
* New topLevel loads get the nsILoadInfo.openerPolicy of the current top level document
* Parsing the Cross-Opener-Origin-Policy of a channel will update mLoadInfo.openerPolicy and this value will get propagated to the child process.
* SessionStore now checks nsIHttpChannel.hasCrossOriginOpenerPolicyMismatch (preffed off) and performs a process switch if needed
Differential Revision: https://phabricator.services.mozilla.com/D19000
--HG--
rename : toolkit/components/remotebrowserutils/tests/browser/browser_httpResponseProcessSelection.js => toolkit/components/remotebrowserutils/tests/browser/browser_httpCrossOriginOpenerPolicy.js
extra : moz-landing-system : lando
Issues were occuring where a process swap would be decided upon during
on-examine-response, but before the swap could be handled by the
channel, the channel was redirected.
This new code takes the mildly hacky approach of simply using a separate
observer notification which is fired at the correct time. A better
solution may be to use a dedicated service for responding to these
events, however that was not implemented for this initial patch.
Depends on D18606
Differential Revision: https://phabricator.services.mozilla.com/D19691
--HG--
extra : moz-landing-system : lando
Issues were occuring where a process swap would be decided upon during
on-examine-response, but before the swap could be handled by the
channel, the channel was redirected.
This new code takes the mildly hacky approach of simply using a separate
observer notification which is fired at the correct time. A better
solution may be to use a dedicated service for responding to these
events, however that was not implemented for this initial patch.
Depends on D18607
Differential Revision: https://phabricator.services.mozilla.com/D19691
--HG--
extra : source : 3d24e8e81c02af9d1edec7571afecefb0d2f1eb4
