We were escaping "/" to "\/", but about:memory expects us to escape "/" to "\".
Escaping "/" to "\/" is probably quite sensible, since then we can represent strings which have both "\" and "/". But that's a bigger change.
We were escaping "/" to "\/", but about:memory expects us to escape "/" to "\".
Escaping "/" to "\/" is probably quite sensible, since then we can represent strings which have both "\" and "/". But that's a bigger change.
The JS engine fires this callback when the request count drops to zero, and we
use it determine when we should hibernate the watchdog thread. But since the
request count never drops to zero for nested event loops, the watchdog never
runs in those cases. And since our xpcshell harness runs tests in a nested event
loop, this means we can't test watchdog hibernation from xpcshell. And we don't
want to test it in mochitests, because the non-determinism of timer CCs and GCs
are likely to be problematic.
Really, we should consider finding a way to integrate nested event loops into
the activity callback mechanism, and should probably get a bug on file. But such
a task is out of scope for this bug, so we just add a way to fake it.
We need this even for testing wakeups, because we can't be certain that any
given operation callback was necessarily triggered from the watchdog thread
(since it's triggered from within the JS engine in various cases as well).
This is a long-overdue change in general. It's now particularly necessary
because we want to start and stop the watchdog, potentially multiple times
during a session. Encapsulating this into a class that we can
destroy/instantiate several times means that we don't end up with inconsistent
state.
As a nice bonus, this centralizes the whole setup and makes it easier to
comprehend. I actually had this nicely split up into several patches, but
I accidentally squashed them while rebasing. :-(
XPCShell currently overrides all the JSContexts whose creation it observes with
its own custom error reporter. This reporter does all sorts of funny things which
we try to clean up for the most part. But there are a few very intricate
considerations at play.
First, the old xpcshell error reporter does some mumbo jumbo with the
XPCCallContext stack to try to guess whether some other code might catch the
exception. This is total garbage on a number of fronts, particularly because
the XPCCallContext stack has no concept of saved frame chains, nested event
loops, sandbox boundaries, origin boundaries, or any of the myriad of
complicating factors that determine whether or not an exception will propagate.
So we get rid of it. But this causes some crazy debugger tests to fail, because
they rely on an exception from uriloader/exthandler/nsHandlerService.js getting
squelched, and can't handle anybody reporting errors to the console service at
the particular moment of contortionism when the exception is raised. So we need
to introduce an explicit mechanism to disable the error reporter here to keep
things running.
Second, we have to be very careful about tracking the return status of the
xpcshell binary. The old code would simply flag an error code if the error
handler was invoked, and we can mostly continue to do that. But there are some
complications. See the comments.
Finally, we don't anything analogous in XPCShellEnvironment, because I have
patches in bug 889714 to remove its state-dependence on the error reporter.
I'll switch it to SystemErrorReporter in that bug.
XPCShell currently overrides all the JSContexts whose creation it observes with
its own custom error reporter. This reporter does all sorts of funny things which
we try to clean up for the most part. But there are a few very intricate
considerations at play.
First, the old xpcshell error reporter does some mumbo jumbo with the
XPCCallContext stack to try to guess whether some other code might catch the
exception. This is total garbage on a number of fronts, particularly because
the XPCCallContext stack has no concept of saved frame chains, nested event
loops, sandbox boundaries, origin boundaries, or any of the myriad of
complicating factors that determine whether or not an exception will propagate.
So we get rid of it. But this causes some crazy debugger tests to fail, because
they rely on an exception from uriloader/exthandler/nsHandlerService.js getting
squelched, and can't handle anybody reporting errors to the console service at
the particular moment of contortionism when the exception is raised. So we need
to introduce an explicit mechanism to disable the error reporter here to keep
things running.
Second, we have to be very careful about tracking the return status of the
xpcshell binary. The old code would simply flag an error code if the error
handler was invoked, and we can mostly continue to do that. But there are some
complications. See the comments.
Finally, we don't anything analogous in XPCShellEnvironment, because I have
patches in bug 889714 to remove its state-dependence on the error reporter.
I'll switch it to SystemErrorReporter in that bug.
XPCShell currently overrides all the JSContexts whose creation it observes with
its own custom error reporter. This reporter does all sorts of funny things which
we try to clean up for the most part. But there are a few very intricate
considerations at play.
First, the old xpcshell error reporter does some mumbo jumbo with the
XPCCallContext stack to try to guess whether some other code might catch the
exception. This is total garbage on a number of fronts, particularly because
the XPCCallContext stack has no concept of saved frame chains, nested event
loops, sandbox boundaries, origin boundaries, or any of the myriad of
complicating factors that determine whether or not an exception will propagate.
So we get rid of it. But this causes some crazy debugger tests to fail, because
they rely on an exception from uriloader/exthandler/nsHandlerService.js getting
squelched, and can't handle anybody reporting errors to the console service at
the particular moment of contortionism when the exception is raised. So we need
to introduce an explicit mechanism to disable the error reporter here to keep
things running.
Second, we have to be very careful about tracking the return status of the
xpcshell binary. The old code would simply flag an error code if the error
handler was invoked, and we can mostly continue to do that. But there are some
complications. See the comments.
Finally, we don't anything analogous in XPCShellEnvironment, because I have
patches in bug 889714 to remove its state-dependence on the error reporter.
I'll switch it to SystemErrorReporter in that bug.
Many of the moved variables are likely not needed. moz.build should one
day validate the sandbox's output and error if "useless" variables are
present.
--HG--
extra : rebase_source : 3abdea056c18d00ede8c15b37db60532eca58630
We only use XPCCallContext for reflector calls now, at which point an AddRef
is totally insignificant. Using an auto pointer here lets us clean up some
code, and makes the XPCCallContext destructor start to look pretty sane. :-)
We now have the invariant that any in-use cx must be pushed onto the JSContext
stack with one of our stack-scoped automatic nsCxPusher classes. These classes
hold a strong ref to the nsIScriptContext associated with the JSContext they
push (if any). This means that, if this cx is in use, we will always have at
least one strong reference to the nsJSContext coming from the stack, meaning
that neither the destructor nor the Unlink() implementation will be called.
So we don't need to do any deferred destruction of the cx anymore.
This test calls the version() shell command, and expects it to work like an
override, rather than the dumb compartment-mutator that I'm turning it into.
Let's just kill the test.
Sandboxes always default to JSVERSION_DEFAULT in the browser. But XPCShell sets
up a ContextCallback that does JS_SetVersion(cx, JSVERSION_LATEST) on every
context that gets created, including the ephemerial Sandbox JSContexts. Since
httpd.js runs in xpcshell and evaluates SJS in a sandbox, we've (somewhat
accidentally) supported JSVERSION_LATEST in SJS, which certain SJS files have
taken advantage of. Let's continue to support it explicitly.
