This commit changes all bulk-memory instructions to perform up-front bounds
checks and trap if any access would be out-of-bounds before writing.
This affects:
* memory.init,copy,fill
* table.init,copy,fill
* data segment instantiation (reduces to memory.init)
* elem segment instantiation (reduces to table.init)
Spec issue: https://github.com/WebAssembly/bulk-memory-operations/issues/111
Differential Revision: https://phabricator.services.mozilla.com/D51755
--HG--
extra : moz-landing-system : lando
I found that this test sometime would fail on the try server, and the reason is that the child document doesn't be activated correctly even if we have called `synthesizeMouseAtCenter()`.
In order to reduce the dependency of other modules, which might affect synthesizing event, we should use `notifyUserGestureActivation` to ensure that we indeed activate the document.
Differential Revision: https://phabricator.services.mozilla.com/D51685
--HG--
extra : moz-landing-system : lando
As `ApproverDocOf()` uses `docshell::GetInProcessSameTypeRootTreeItem()`, which is not compatible in Fission because we are not able to get the top document if we are in the remote process. Therefore, we should check browsering content directly instead, because the user activation state would be sync automatically for each top-level browsing context among different processes.
Differential Revision: https://phabricator.services.mozilla.com/D51427
--HG--
extra : moz-landing-system : lando
Standardize the jsapi-tests logic to match the other spidermonkey check
commands in testing/mach_commands.py.
Differential Revision: https://phabricator.services.mozilla.com/D51530
--HG--
extra : moz-landing-system : lando
There were 3 checks for this preference. Prior to bug 1079355 which ignored the
pref for system principals, the checks were all straightforward pref checks.
The conditionals are somewhat confusing as written. The main idea is the code
inside the blocks only executes if:
- The preference is disabled.
- The RV was success (we don't want to steal error handling, just prevent
success.)
- We're not dealing with the system principal.
As such, I'm removing the full conditional blocks.
Differential Revision: https://phabricator.services.mozilla.com/D51672
--HG--
extra : moz-landing-system : lando
Using a data URL makes the request not use the proxy and so it will not mess up the session count
Differential Revision: https://phabricator.services.mozilla.com/D51843
--HG--
extra : moz-landing-system : lando
* Adds a new moz-http2-child.js file which gets spawned into a new process. When calling NodeServer.execute, the code gets passed to the existing moz-http2.js process which then sends it to be evaluated in the child process. Any crash in the child should not be able to kill the main node process.
* Moves the proxy creation code into test_http2-proxy.js
* Adds the new NodeServer.fork() and NodeServer.kill() static methods to spawn a new server
* Makes it easier to isolate a test's behaviour from another's. It also opens the way to moving some of the logic to individual unit tests, like we do for the proxy creation code, rather than keeping it all in moz-http2.js
Differential Revision: https://phabricator.services.mozilla.com/D49961
--HG--
extra : moz-landing-system : lando
Running this test leads to intermittent "unable to find test window"
failures on 32 bit windows. If the timeout to get_test_window() in
executormarionette.py is increased, the failure goes away, but there
is no way in the framework to increase this timeout for a single
test.
Differential Revision: https://phabricator.services.mozilla.com/D51618
--HG--
extra : moz-landing-system : lando
I forgot about Reflect.cpp after the initial changes and borked it. This fixes it!
Differential Revision: https://phabricator.services.mozilla.com/D51572
--HG--
extra : moz-landing-system : lando
nsIDOMWindow is now an empty interface. There are two references to
nsIDOMWindow::openDialog in comments which needed to be updated. There
were also a few forward declarations of nsIDOMWindow that were unused.
Differential Revision: https://phabricator.services.mozilla.com/D51738
--HG--
extra : moz-landing-system : lando
This is the third, and final, part of a patch that adds chrome support to raptor-browsertime.
In this part, all the changes from the previous 2 parts are integrated in raptor and browsertime. The main change is that the browsertime-chromedriver paths created in taskcluster's `tests.py` are changed to include a `{}` for inserting the chrome version that is used in production (formatting is done within raptor). The Perftest class structure is slightly modified as well here to accommodate these changes.
There are also some changes to how the taskcluster definitions are made to make it easier to specify how chrome must be handled. The 'limit-platforms' and 'run-visual-metrics' fields are added for this purpose to limit chrome's platforms and disable visual-metric tasks.
Finally, chrome is missing some results in browsertime (relative to firefox) and at least one of the other results is scattered into a different location. The results.py and output.py changes handle this issue.
Differential Revision: https://phabricator.services.mozilla.com/D48898
--HG--
extra : moz-landing-system : lando
This is the second part of a patch that adds chrome support to raptor-browsertime.
This part of the patch adds fetch tasks to handle multiple chrome versions running in production. These fetch tasks provide a tar that the chrome browsertime can use to get a chromedriver compatible with the chrome version available on the testing machine. The artifacts are converted to `.tar.zst` so that they can be prefixed with the chome version that they are compatible with.
Differential Revision: https://phabricator.services.mozilla.com/D48897
--HG--
extra : moz-landing-system : lando
This is the first part of a patch that adds chrome support to raptor-browsertime.
In this patch, a get_browser_meta function is added which returns the name and version of the browser being tested. This version will then be used (in part 3) in the variable passed in through --browsertime-chromedriver (only when running not locally, or if we find {} in the string).
Differential Revision: https://phabricator.services.mozilla.com/D48895
--HG--
extra : moz-landing-system : lando