I changed DelegatedQueryInterface and CallMethod to be non-static
methods rather than taking an explicit |self| parameter.
There is already a method nsXPCWrappedJS::CallMethod() with the same
signature, but it is a shim, so I inlined it into the version in
XPCWrappedJSClass.cpp.
I also fixed up a few comments that mention nsXPCWrappedJSClass.
The new comments starting with "We now need to enter the realm" were
written by Boris, and are a little more explicit so they are easier to
understand.
I renamed DebugDump() to DebugDumpInterfaceInfo() to be more
informative.
Differential Revision: https://phabricator.services.mozilla.com/D26422
--HG--
extra : moz-landing-system : lando
I changed DelegatedQueryInterface and CallMethod to be non-static
methods rather than taking an explicit |self| parameter.
I did a tiny bit of cleanup in the nsIXPConnectJSObjectHolder case of
DelegatedQueryInterface().
There is already a method nsXPCWrappedJS::CallMethod() with the same
signature, but it is a shim, so I inlined it into the version in
XPCWrappedJSClass.cpp.
I also fixed up a few comments that mention nsXPCWrappedJSClass.
The new comments starting with "We now need to enter the realm" were
written by Boris, and are a little more explicit so they are easier to
understand.
I renamed DebugDump() to DebugDumpInterfaceInfo() to be more
informative.
Differential Revision: https://phabricator.services.mozilla.com/D26422
--HG--
extra : moz-landing-system : lando
nsXPCWrappedJSClass now only adds indirections and dynamic
allocations, so eliminate it. The class is kept around as a collection
of static helper functions to avoid needing to move around all of this
code and messing with history. In total, these patches save around 2kb
of dynamic allocations per process.
The major parts of this patch are:
* Dropping indirection for accessing things on nsXPTInterfaceInfo and
renaming things from class to info.
* Removing the stuff related to instances of nsXPCWrappedJSClass
existing (ctor, dtor, field, ISupports implementation, getter methods).
* Removing IID2WrappedJSClassMap, because we only need the map from IIDs
to info.
I dropped the null check in TraverseNative because mInfo is never
cleared, while mClass was.
I dropped the forward declaration of nsXPCWrappedJSClass because no
instances of that class exist, so no function will take or return a
pointer to one.
Differential Revision: https://phabricator.services.mozilla.com/D26218
--HG--
extra : moz-landing-system : lando
Ultimately, this method is really about dumping XPConnect-ish
information about an nsXPTInterfaceInfo, so change it into a static
method that takes an info directly. This loses logging of the
nsXPCWrappedJSClass's ref count, but that is going away in the next
patch anyways.
Differential Revision: https://phabricator.services.mozilla.com/D26217
--HG--
extra : moz-landing-system : lando
This interface serves no real purpose, aside from some weird XPConnect
debugging function. If you are in a debugger already, you can just
call the nsXPCWrappedJSClass DebugDump method directly.
For now, I changed nsXPCWrappedJSClass to just implement nsISupports,
but this will go away later.
I also devirtualized DebugDump(), because it is no longer an XPCOM
method.
Differential Revision: https://phabricator.services.mozilla.com/D26216
--HG--
extra : moz-landing-system : lando
The first idea here is that |this| is actually the GetClass() of the
|wrapper| argument (the one call site looks like
"GetClass()->CallMethod(this, ...)"), so we can locally reconstruct it
when CallMethod is a static method.
The second idea here is that the only real use of the
nsXPCWrappedJSClass is to grab some data from the nsXPTInterfaceInfo
in a few places. This means that we can take a pointer to the info
early on in the function and use that rather than go through the
nsXPCWrappedJSClass. This in turn means that because the info is
statically allocated we no longer need to do a kungFuDeathGrip on the
wrapper's nsXPCWrappedJSClass.
Differential Revision: https://phabricator.services.mozilla.com/D26215
--HG--
extra : moz-landing-system : lando
There are a number of nsXPCWrappedJSClass methods that don't use any
data from |this|, so go ahead and make them static. This is one step
towards eliminating nsXPCWrappedJSClass entirely.
In addition, devirtualize a few methods, because they are going to
have to get devirtualized anyways, and there's no need for them to be
virtual.
Differential Revision: https://phabricator.services.mozilla.com/D26214
--HG--
extra : moz-landing-system : lando
This field now just caches the IsReflectable() field from the method
info, so get rid of it.
Differential Revision: https://phabricator.services.mozilla.com/D26071
--HG--
extra : moz-landing-system : lando
XPCConvert::IsMethodReflectable() is derived entirely from
nsXPTMethodInfo, so we can compute it at build time and include it in
nsXPTMethodInfo. It is the only use of mNotXPCOM and mHidden, so we
can get rid of those fields at the same time.
This paves the way for getting rid of XPCWrappedJSClass::mDescriptors
in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D26070
--HG--
extra : moz-landing-system : lando
There is only a single XPC JS runtime now, so there's no need to keep a
special pointer around.
Differential Revision: https://phabricator.services.mozilla.com/D26068
--HG--
extra : moz-landing-system : lando
The change to the second FindTearOff call in XPCWrappedNative::GetNewOrUsed is
fixing a longstanding bug that was introduced in bug 903891 when the sense of
the check was incorrectly reversed. Luckily that code is unreached in
practice, because the two PreCreate hooks we have left never create the wrapper.
Differential Revision: https://phabricator.services.mozilla.com/D26007
--HG--
extra : moz-landing-system : lando
This field now just caches the IsReflectable() field from the method
info, so get rid of it.
Differential Revision: https://phabricator.services.mozilla.com/D26071
--HG--
extra : moz-landing-system : lando
XPCConvert::IsMethodReflectable() is derived entirely from
nsXPTMethodInfo, so we can compute it at build time and include it in
nsXPTMethodInfo. It is the only use of mNotXPCOM and mHidden, so we
can get rid of those fields at the same time.
This paves the way for getting rid of XPCWrappedJSClass::mDescriptors
in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D26070
--HG--
extra : moz-landing-system : lando
There is only a single XPC JS runtime now, so there's no need to keep a
special pointer around.
Differential Revision: https://phabricator.services.mozilla.com/D26068
--HG--
extra : moz-landing-system : lando
1. Adding a new attribute chromeContext in ConsoleEvent
2. Adding a new boolean attribute isFromChromeContext in nsIConsoleMessage
3. Sending IsFromChromeContext to the parent process
Differential Revision: https://phabricator.services.mozilla.com/D23330
--HG--
extra : moz-landing-system : lando
Left shifts exhibit undefined behavior if the sign bit changes, which
would happen in this code for indices that are 31 mod 32. Fix this by
always making sure the shifted value is an unsigned integer.
Differential Revision: https://phabricator.services.mozilla.com/D25476
--HG--
extra : moz-landing-system : lando
This ensures the JS shell and browser behave the same way and it's nice for fuzzing.
Differential Revision: https://phabricator.services.mozilla.com/D25204
--HG--
extra : moz-landing-system : lando
Also adds a javascript.options.ion.full.threshold browser pref and similar shell
flags.
This doesn't rename the existing prefs yet.
Differential Revision: https://phabricator.services.mozilla.com/D24156
--HG--
extra : moz-landing-system : lando
In bug 256180, the size of the stack on 64-bit Windows was changed from 2MB to
8MB, and on 32-bit Windows, from 1MB to 1.5MB. This is so large that it takes
significantly longer for a runaway recursive function to throw "too much
recursion", which causes terrible performance in scripts obfuscated using
obfuscator.io.
This patch leaves the actual stack size as-is, but changes the
JS-engine-specific stack quota back to 2MB on 64-bit Windows (6MB if ASAN is
enabled). 32-bit Windows is unaffected by the new cap.
Differential Revision: https://phabricator.services.mozilla.com/D24597
--HG--
extra : moz-landing-system : lando
1. Adding a new attribute chromeContext in ConsoleEvent
2. Adding a new boolean attribute isFromChromeContext in nsIConsoleMessage
3. Sending IsFromChromeContext to the parent process
Differential Revision: https://phabricator.services.mozilla.com/D23330
--HG--
extra : moz-landing-system : lando
Replaced instances of callers in both C++ and JS files to query the state from the principal directly.
Differential Revision: https://phabricator.services.mozilla.com/D22532
--HG--
extra : moz-landing-system : lando
Noticed by Ian Moody [:Kwan] while watching test output. (!)
The test was introduced in bug 515475, 10 years ago. However, the syntax used
in this patch seems to have been removed from SpiderMonkey around that time,
maybe even before the patch landed; that is, this is not among the syntax
removed in bug 517580. As far as I can tell, this test has never functioned
properly.
Differential Revision: https://phabricator.services.mozilla.com/D24236
--HG--
extra : moz-landing-system : lando
This creates a shell command-line option, `--enable-experimental-fields`, and a
Gecko pref, `javascript.options.experimental.fields`.
Both are off by default everywhere, for now.
Differential Revision: https://phabricator.services.mozilla.com/D22045
--HG--
extra : moz-landing-system : lando
This creates a shell command-line option, `--enable-experimental-fields`, and a
Gecko pref, `javascript.options.experimental.fields`.
Both are off by default everywhere, for now.
Differential Revision: https://phabricator.services.mozilla.com/D22045
--HG--
extra : moz-landing-system : lando
`CompartmentPrivate::GetScope()` was added so callers don't have to do `scope.get()`
manually. The `scope` field is now private and was renamed to `mScope`.
Also replaces some `CompartmentPrivate::Get(obj)->scope` instances with
`ObjectScope(obj)`. It's equivalent but shorter.
Differential Revision: https://phabricator.services.mozilla.com/D22664
--HG--
extra : moz-landing-system : lando
XPCWrappedNativeScope is now allocated and destroyed with the CompartmentPrivate
that owns it. In follow-up bugs we could merge the two classes (see bug 1032928).
This also removes the dying-scopes list. XPCJSRuntime now stores the list of all
scopes as mozilla::LinkedList.
Differential Revision: https://phabricator.services.mozilla.com/D22492
--HG--
extra : moz-landing-system : lando
Renamed the test to reflect that it is really just a test of the script preloader
as well. I just moved it to get it close to the ScriptPreloader and near existing
tests.
Differential Revision: https://phabricator.services.mozilla.com/D22330
--HG--
rename : testing/marionette/harness/marionette_harness/tests/unit/test_startup_caches.py => js/xpconnect/tests/marionette/test_preloader_telemetry.py
extra : moz-landing-system : lando
Hiding document.createEvent("TouchEvent"), document.createTouch, document.createTouchList and ontouch* event
handlers on desktop to follow what Chrome has done.
This patch explicitly does not remove createTouch or createTouchList everywhere, although those seem to have been
removing already on some other browsers.
Devtools use TOUCHEVENTS_OVERRIDE_ENABLED for touch event testing, and this patch keeps the old behavior per discussion
with devtools devs.
Differential Revision: https://phabricator.services.mozilla.com/D22081
--HG--
extra : rebase_source : 562588a289632ba2f11db7f3ac8782c26c3b05f8
In bug 1264235 we have some indication that observed bugs with the
startup cache might have been resolved, but we don't really know
until we collect data. Collecting these stats will give us the
ability to have more certainty that the startup cache is functioning
correctly in the wild.
Differential Revision: https://phabricator.services.mozilla.com/D19573
--HG--
extra : moz-landing-system : lando