The grammar changes parallel those in https://github.com/heycam/webidl/pull/700
We don't prevent having both a constructor operation and [Constructor] or
[ChromeConstructor], because those extended attributes are about to get
removed, once they are no longer used in our IDL.
Differential Revision: https://phabricator.services.mozilla.com/D45387
--HG--
extra : moz-landing-system : lando
Right now, we end up with the forward declaration of
nsIDOMWindowProxy, which does not exist, instead of the proper type.
Differential Revision: https://phabricator.services.mozilla.com/D45516
--HG--
extra : moz-landing-system : lando
This is so that SetUseCounter is as cheap as possible.
This is in preparation for hooking the CSS use counters to telemetry. We want
CSS use counters to be fast and be propagated at once to the parent page. This
will make sure to use the same setup as everywhere else.
Differential Revision: https://phabricator.services.mozilla.com/D44645
--HG--
extra : moz-landing-system : lando
This check is used to reject cross-origin objects from being passed in
as |any| or |object| parameters to WebIDL methods. Remote object
proxies are technically same-origin, but we want to make them behave
the same as when Fission is not enabled.
Differential Revision: https://phabricator.services.mozilla.com/D43105
--HG--
extra : moz-landing-system : lando
This check is used to reject cross-origin objects from being passed in
as |any| or |object| parameters to WebIDL methods. Remote object
proxies are technically same-origin, but we want to make them behave
the same as when Fission is not enabled.
Differential Revision: https://phabricator.services.mozilla.com/D43105
--HG--
extra : moz-landing-system : lando
These test that various DOM things fail when done
cross-origin. They'll fail in a different way if done cross-process,
so change the origin used so that it is same-process, but
cross-origin, even with Fission.
Differential Revision: https://phabricator.services.mozilla.com/D42678
--HG--
extra : moz-landing-system : lando
The nsAString overload of GetCallingLocation directly converts the
original source file name string into an nsAString. A number of
callers that want the source file name in an nsAString are calling the
nsACString overload of GetCallingLocation, then calling
NS_ConvertUTF8toUTF16. This results in an extra intermediate copy of
the original string data.
Differential Revision: https://phabricator.services.mozilla.com/D42727
--HG--
extra : moz-landing-system : lando
Add IDLInterfaceMixin with a new superclass shared with existing IDLInterfaceOrNamespace.
Differential Revision: https://phabricator.services.mozilla.com/D38802
--HG--
extra : moz-landing-system : lando
JSClass contained void* members corresponding to the internal pointer members of js::Class. This stores the internal members in JSClass and removes js::Class.
This leaves js::Class aliased to JSClass while we remove references to it. I also aliased Jsvalify and Valueify into global scope temporarily to make this compile. These get removed in the following patches.
I had to remove a few functions which now don't compile with js::Class being the same type as JSClass.
Differential Revision: https://phabricator.services.mozilla.com/D41983
--HG--
extra : moz-landing-system : lando
The problem is that if there is a leak at shutdown we can end up calling ClearWrapper on a wrapper that has already been cleared by the JS engine. The patch just relaxes the assertion to allow this. I tested this on try with a bunch of retriggers and it seems to fix the problem.
Differential Revision: https://phabricator.services.mozilla.com/D41938
--HG--
extra : moz-landing-system : lando
Otherwise we're computing (1ull << CHAR_BIT) * sizeof(...), which is not
quite what we wanted.
Differential Revision: https://phabricator.services.mozilla.com/D41773
--HG--
extra : moz-landing-system : lando
Merge js::FreeOp and JSFreeOp, but alias the former to the latter while we fix uses.
Differential Revision: https://phabricator.services.mozilla.com/D41410
--HG--
extra : moz-landing-system : lando
Merge js::FreeOp and JSFreeOp, but alias the former to the latter while we fix uses.
Differential Revision: https://phabricator.services.mozilla.com/D41410
--HG--
extra : moz-landing-system : lando
All .xul files have been loading as HTMLDocuments for a few weeks now, so
it should be safe to remove the XULDocument implementation.
Differential Revision: https://phabricator.services.mozilla.com/D41238
--HG--
extra : moz-landing-system : lando
`except Exception as exception` in Python 3 removes the `exception` variable in the outer scope whereas Python 2 does not. This mitigates the error caused by the Py3 behavior.
Differential Revision: https://phabricator.services.mozilla.com/D41194
--HG--
extra : moz-landing-system : lando
We could get rid of the need to specify the impl class at the callsite by
taking a T** instead of returning an already_AddRefed<T>, but I'm not sure
which is uglier...
The change from `globalHolder->GetGlobalJSObject()` to `global.Get()` is OK,
because `globalHolder` was coming from the nsISupports attached to
`global.Get()` anyway, so those are the same global JS object.
Differential Revision: https://phabricator.services.mozilla.com/D40060
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
When we call GetRemoteOuterWindowProxy in the middle of a transplant,
the remote proxy that the function returns will be almost immediately
swapped with some other object. Rather than trying to fix up the
remote proxy map when that happens, this patch adds a new argument
that is a pointer to the object, if any, that the remote proxy is
going to be swapped to. This will be used in the remote proxy map.
Having a value in the remote proxy map that is not a remote proxy
could cause issues if somebody ends up calling
GetRemoteOuterWindowProxy() a second time before the transplant has
finished. To avoid that, my patch asserts that we are returning an
object with the appropriate class.
Differential Revision: https://phabricator.services.mozilla.com/D37598
--HG--
extra : moz-landing-system : lando
