In the old world, we'd be saved by initializing the SafeJSContext early enough
that we'd short-circuit in the nsContentUtils::IsInitialized() check. That's not
the case anymore, so let's hande this explicitly.
This brings us into alignment with nsContentUtils::IsCallerXBL(). We also take
the opportunity to clean up some comments and invariants that changed with the
removal of the XBL bit.
I looked through the NSPR socket creation functions that InitWithAddress
uses to see which errors they could return, and placed appropriate comments
in ErrorAccordingToNSPR.
The test coverage is not great; in particular, I wasn't able to find a way
to elicit "address in use" errors from Windows (although I could from
Linux); the web says that Windows is much more relaxed about binding
listening sockets than Unix derivatives. I'm interested in suggestions.
I broke out this this change on its own, because it seemed to require some care:
PR_ADDRESS_NOT_SUPPORTED_ERROR used to be lumped in with several other NSPR
error codes and reported as NS_ERROR_CONNECTION_REFUSED; and a dumb grep shows
that the NS_ERROR_ is widely checked for. Introducing the distinction might
require the new NS_ERROR_SOCKET_ADDRESS_NOT_SUPPORTED value to be checked for
everywhere that currently checks for NS_ERROR_CONNECTION_REFUSED.
But that seems unlikely to be necessary: first of all, it shouldn't really
be possible, via the XPCOM interface, to force this error path to occur at
present: the components' implementations are in complete control over which
socket address types get used. I also did a Try push with a call to
NS_ABORT if a PR_ADDRESS_NOT_SUPPORTED_ERROR ever flows through
ErrorAccordingToNSPR; there were no crashes.
But if that's so, then why introduce the new error code at all? A later
patch adds support for Unix-domain sockets, a type of socket address which
is *not* supported on non-Unix systems. In that case, a distinct error code
will help people diagnose problems quickly.
This brings us into alignment with nsContentUtils::IsCallerXBL(). We also take
the opportunity to clean up some comments and invariants that changed with the
removal of the XBL bit.
We need to simultaneously report the new Heap Pointer to the cycle collector,
and remove the old machinery for cycle-collecting the default object via the
JSContext.
We don't cycle collect any other kind, so there's no difference between marking
them gray and letting the JS engine mark them black. This also gets rid of that
nasty code which reset the flag, which billm theorizes has to do with faulty
logic in ContextHolder when creating ephemeral sandbox cxes. The assertion in
this patch should catch us if anything goes wrong.
