This patch was generated by my modeline.py script.
MozReview-Commit-ID: EbVjPLwiUAT
Depends on D4159
Differential Revision: https://phabricator.services.mozilla.com/D4161
--HG--
extra : moz-landing-system : lando
We want to be able to enter the Realm we were in when the callback was created
before calling it, but if the callback stores a cross-compartment wrapper we
don't really have a good way to find that Realm. So we store it explicitly by
storing a global when the callback is created.
The changes to the constructor signatures to use JSObject* instead of
JS::Handle<JSObject*> are so we can avoid having to root the global for these
calls. These changes make two of the constructors ambiguous when nullptr is
being passed for the first arg; this patch adds casts to disambiguate.
This does mean that if the node is adopted back into the original document the
expandos would end up on the reflector at that point. I think that's OK;
people shouldn't be adopting things in that direction. Futhermore, if they
adopt, then set expandos, then adopt back they already get this behaviorl
So if we decide we don't want that, we should probably just avoid copying own
props when reparenting into a global whose principals don't subsume the old
global.
Because of modifications to the DataTransfer constructors, the status of the tests that use DataTransfer objects had to be changed to reflect the fact that those tests now pass. Additionally, a test had to be deleted because it tested an obscure situation using the old Chrome only constructor.
MozReview-Commit-ID: LOWuPwh0NeW
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
These are cases that are implementing the "convert an exception to a Promise"
steps of the Web IDL spec. Typically the exception is thrown in the current
compartment; the Promise returned should simply match that. Otherwise we can
end up with a situation in which the promise doesn't actaully have access to
its rejection value, which will cause problems if someone uses then() on the
promise: the return value of the then() call will get a sanitized exception
instead of the real one.
We _could_ try to match the actual compartment of the exception, in theory.
But it's not clear why this would be preferable to using the current
compartment, even if there were cases in which the exception _doesn't_ match
the current compartment. Which there likely are not.
MozReview-Commit-ID: Ac2BHIHxfvY
--HG--
rename : dom/promise/tests/test_promise_argument.html => dom/promise/tests/test_promise_retval.html
rename : dom/promise/tests/test_promise_argument_xrays.html => dom/promise/tests/test_promise_retval_xrays.html
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
The "body" part of responsexml-document-properties.htm is not really per current
spec text, and fails in every non-Firefox browser, and in Firefox after this
change. https://github.com/w3c/web-platform-tests/issues/2668 tracks this issue
to some extent, but if all browsers are going to align here anyway, we should
just adjust the test and move on.
MozReview-Commit-ID: HTLfggvi5LL
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
The renaming here is like this:
SetStringBuffer -> SetKnownLiveStringBuffer
SetEphemeralStringBuffer -> SetStringBuffer
SetOwnedString -> SetKnownLiveString
SetOwnedAtom -> SetKnownLiveAtom
This should make it clearer what the lifetime expectations are on the caller side.
MozReview-Commit-ID: ERHbB3r6paN
When defining WebIDL constants in C++, we may need to undefine some
constant names that conflict with windows.h preprocessor defines.
Doing this in the binding header is far easier than tracking down the
include orders that may cause conflicts.
MozReview-Commit-ID: A0UoYezIQs5
--HG--
extra : rebase_source : d9100af2ccdb5c6e6468542ac68f74b2e4f9050c
This was automatically generated by the script modeline.py.
MozReview-Commit-ID: BgulzkGteAL
--HG--
extra : rebase_source : a4b9d16a4c06c4e85d7d85f485221b1e4ebdfede