When we did the major cairo update in bug 739096, most of our old patch files were superseded
and no longer relevant, but I failed to clean them up at the time. So here, we remove all the
old patch files, and create new ones just for the fixes we've applied on top of the new code
from upstream.
I've omitted patch files for fixes that I am aware have already landed upstream, as those will
automatically be included in any future update we take. (It's possible more of the new patch
files will also be obsolete by the time we try pulling a new version, but at least they should
provide a starting point.)
Differential Revision: https://phabricator.services.mozilla.com/D164680
This is a slightly annoying thing that can happen. When we abruptly cancel (such as an infinitely
running script being forcibly terminated) we will be in a state where the EvaluateModule call will
finish _after_ the loader is destroyed. So, instead we track if there has been a forcible
cancelation, and exit early.
Depends on D155690
Differential Revision: https://phabricator.services.mozilla.com/D155568
In our implementation, we do not have "client" as a referrer, so we resolve the URI directly as part
of ScriptLoadRequest creation.
Depends on D147327
Differential Revision: https://phabricator.services.mozilla.com/D155567
ImportScripts should be disallowed for module works, which are initialized in the following way:
`new Worker("url", { module:true})`. We set the WorkerType for workers accordingly, and can use that
to detect if import scripts are being incorrectly used.
Depends on D147326
Differential Revision: https://phabricator.services.mozilla.com/D147329
This implements a method to initialize the moduleLoader for workers. This will initialize only once, for all worker types (module and classic).
Depends on D147324
Differential Revision: https://phabricator.services.mozilla.com/D147326
This doesn't actually move the timer onto the document.
Instead it is the correct manual juggling of pointers via `.forget()` and `NS_RELEASE()` and some additional testing to make sure it works properly.
This passes tests where we resolve, reject immediately, and reject on timeout and has no leaks in all of those cases.
Putting the timer on the document also required putting the pending promise onto the document with it and that had further wrinkles.
I call that good enough.
Differential Revision: https://phabricator.services.mozilla.com/D164260
Similar to the previous patch, but for setters.
The `WindowProxy` optimization for `SetProp` currently only supports data properties,
so there's only the set-name case we have to change.
Differential Revision: https://phabricator.services.mozilla.com/D164542
Before this patch, we supported only native getters that can take the global object
as `this` argument (DOM getters) for `GetProp` on `WindowProxy` and `GetGName`.
This patch extends this to also support getters (native and scripted) that need
the `WindowProxy` if we have one.
Differential Revision: https://phabricator.services.mozilla.com/D164541
This way we don't have to recompute the `kind` by calling `IsCacheableGetPropCall`
a second time. We still assert the values match in debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D164540
Trivial-ish backout (with a change from click() to doCommand(), which
also works around the issue described in the original commit).
MANUAL PUSH: Test-only to keep the tree green CLOSED TREE
Bug 1805414 will move menu event handling to the DOM.
With that change the current synthetic click behavior of XUL menuitems
breaks. On current central, we rely on nsMenuFrame::HandleEvent not
getting called at all for synthetic clicks, and instead we just fire a
command event synchronously here:
https://searchfox.org/mozilla-central/rev/a0d4f8f112c5c792ae272bf6ce50763ddd23ffa2/dom/xul/nsXULElement.cpp#1071
After my patch the command event is fired properly (potentially
asynchronously too) by the regular menu activation machinery, which is
preferable.
* They fire a command event synchronously (even though on some
platforms like macOS activating a context menu item is async).
* They use a totally different codepath from what a user does.
* They don't deal with native menus, etc.
We have a proper API for this (activateItem) which takes a much more
closer codepath to what users do, requires that the menu is shown, etc.
Use that API instead for testing.
As a benefit, tests now do not need to close the context menu manually
when clicking on a menu item (because we trigger the same code path as
users clicking the menu).
Differential Revision: https://phabricator.services.mozilla.com/D164567
This updates the docker image used for CI on the github.com webrender
repository, so that updates to the WebRender code can continue to be
propagated to github.
Differential Revision: https://phabricator.services.mozilla.com/D164458
