This implementation allows for the old behavior, returning a plain
object, if these functions are given no argument, while providing the
new behavior, querying the build/realm configuration, if an argument is
given.
Differential Revision: https://phabricator.services.mozilla.com/D188788
- check for clean mercurial repo
- check for pre-exiting github repo
- make sure the patch-stack passes verify_vendoring.sh
- add flag to skip startup sanity checks for scripts like loop-ff.sh
that already verify sanity.
Depends on D188878
Differential Revision: https://phabricator.services.mozilla.com/D188879
Speedometer 3's Charts-chartjs calls this with an object with 10 properties,
so this avoids malloc overhead.
Depends on D188967
Differential Revision: https://phabricator.services.mozilla.com/D188968
We don't need to use the vector in this case because both objects
are plain objects with only data properties.
Depends on D188966
Differential Revision: https://phabricator.services.mozilla.com/D188967
We already had an optimization to reuse the shape when assigning to an empty object.
This often doesn't work because the number of fixed slots is different, but in
this case we can still reuse the property map.
Differential Revision: https://phabricator.services.mozilla.com/D188966
In this test, The worker will load a data URI, which import another test
script statically, and the imported script will import 'export-on-load-script.js',
which will be served with the CORS header 'Access-Control-Allow-Origin: *' in
/workers/modules/resources/export-on-load-script.js.headers
In the test case [Static import (redirect).], 'export-on-load-script.js' will be
redirected, and the redirected script doesn't have the CORS header.
According the current spec, the redirected 'export-on-load-script.js' is
in the same-origin with the document, therefore it should be loaded.
But with Gecko's implementation, the redirected script "export-on-load-script.js"
is cross-origin with the main worker script (which is loaded by data URI),
so the script is blocked.
(The first test case, which tests static import without redirect, the
script 'export-on-load-script.js' could be loaded by Gecko because the
script has the CORS header.)
Mark this test case as failed according to the spec issue
https://github.com/whatwg/html/issues/9571
Differential Revision: https://phabricator.services.mozilla.com/D187901
In the [static import script from data: URL should be allowed.] case,
The worker will load the data URI, which imports "/resources/static-import-script-block-cross-origin.js".
And static-import-script-block-cross-origin.js will static import 'export-block-cross-origin.js'
According to the current spec, the script "export-block-cross-origin.js"
is in the same origin of the document, therefore it should be loaded.
But with Gecko's implementation, the script "export-block-cross-origin.js"
is cross-origin with the main worker script (which is loaded by data URI),
so the script is blocked.
Mark this test case as failed according to the spec issue
https://github.com/whatwg/html/issues/9571
Differential Revision: https://phabricator.services.mozilla.com/D187900
Update `aiohttp` to version 3.8.5 and `requests` to version 2.31.0,
and vendor their respective dependencies. Add all the new dependencies
to the various required site virtualenv requirements files.
Differential Revision: https://phabricator.services.mozilla.com/D188904
ConditionalExpr is the only case I can see where constant-folding can replace
the valid LHS of an OptionalDotExpr with another expression that isn't valid in
the AST. This can happen when the ConditionalExpr is parenthesized, and
maintaining the parentheses keeps the folded expression valid for
OptionalDotExpr.
One alternative to maintaining the parentheses is to check if folding results
in a disallowed expression (not a MemberExpression or CallExpression), and
restoring the unfolded expression if so. Wrapping in parentheses lets us keep
the folding optimization, so it seems better.
Differential Revision: https://phabricator.services.mozilla.com/D187222
Turns out macOS relies on the background being set in the toolbox rather
than :root because we slide the toolbox down entirely when the menubar
shows up in full-screen.
Since this is also the set up we have for lightweight themes and Linux,
and we can change Windows to do the same now that Aero is not a thing
anymore, clean-up the code and move all the toolbox background code to a
shared place.
In the future if we want to do something like Mica / Aero on Windows
again, we could do this trivially by setting --toolbox-non-lwt-bgcolor:
transparent or so on the relevant platform's file.
I can write a simpler patch for beta if needed.
Differential Revision: https://phabricator.services.mozilla.com/D189055
What we are doing in this bug is adding the ability to get motionmark ramp scores for just firefox
Motionmark has issues with other browsers, which is why we are starting with just firefox for now
Differential Revision: https://phabricator.services.mozilla.com/D188120
Recently we added Mac OSX with apple silicon, the chromedrivers used for apple silicon are different than the ones used for non-apple silicon chips
In this patch I add the ability to use differnt chromedrivers for mac by modifying the extracted names section which is where we untar the zipped chromedriver
Differential Revision: https://phabricator.services.mozilla.com/D188265