This is a follow-up to bug 1409249. There are a lot of places where our
factory singleton constructors either don't correctly handle their returned
references being released by the component manager, or do handle it, but in
ways that are not obvious.
This patch handles a few places where we can sometimes wind up with dangling
singleton pointers, adds some explanatory comments and sanity check
assertions, and replaces some uses of manual refcounting with StaticRefPtr and
ClearOnShutdown.
There are still some places where we may wind up with odd behavior if the
first QI for a getService call fails. In those cases, we wind up destroying
the first instance of a service that we create, and re-creating a new one
later.
MozReview-Commit-ID: ANYndvd7aZx
After data delivery for a request has been retargeted, there's no reliable way
to get the appropriate event target to re-dispatch data events after
asynchronous processing.
While it's technically possible to retrieve the current thread from
OnDataAvailable callbacks and re-use that for later dispatch, that approach
has some issues:
1) It's not currently possible to reliably map the current thread to the
thread pool that owns it. That means that if data delivery is being targetted
to a thread pool, attempts to redispatch events to the previous delivery
thread might lead to long delays when one thread in a pool is blocked.
2) If a filter wishes to dispatch data events to the wrapped listeners before
it's recieved any data (as extensions StreamFilters sometimes do), there's no
way to determine the proper event target without waiting for initial data to
be received.
Simply returning the correct event target from the request solves both of
these problems.
MozReview-Commit-ID: CJxq7O4399R
Changes ExtensionProtocolHandler to use remote streams for
moz-extension loads of file and JAR URI's to allow for
filesystem read-access sandboxing.
Adds messaging to PNecko to allow child processes to
request an input stream or file descriptor for moz-extension
URI's.
Add ExtensionProtocolHandler singleton so that NeckoParent can
call methods directly and ExtensionProtocolHandler::NewFD
can use a new member variable |mFileOpenerThread| to open files.
Adds FileDescriptorFile, a limited implementation of nsIFile
that wraps a file descriptor, to be sideloaded into
nsJARChannels so that extension JAR files can be read
using a file descriptor without accessing the filesystem
directly.
MozReview-Commit-ID: 1pcnIpjz2yR
Changes ExtensionProtocolHandler to use remote streams for
moz-extension loads of file and JAR URI's to allow for
filesystem read-access sandboxing.
Adds messaging to PNecko to allow child processes to
request an input stream or file descriptor for moz-extension
URI's.
Add ExtensionProtocolHandler singleton so that NeckoParent can
call methods directly and ExtensionProtocolHandler::NewFD
can use a new member variable |mFileOpenerThread| to open files.
Adds FileDescriptorFile, a limited implementation of nsIFile
that wraps a file descriptor, to be sideloaded into
nsJARChannels so that extension JAR files can be read
using a file descriptor without accessing the filesystem
directly.
MozReview-Commit-ID: 1pcnIpjz2yR
In bug 1353123 it was decided to not extend this telemetry, so it will
expire in this release. Given that, and the fact that bug 1329336 has
disabled the feature already, it's time to remove the probe.
Giving '0' (literal zero) to nsCOMPtr is now ambiguous, as both
nsCOMPtr(decltype(nullptr)) and nsCOMPtr(T*) could be used.
In any case, our coding standards mandate the use of 'nullptr' for pointers.
So I'm changing all zeroes into nullptr's where necessary.
MozReview-Commit-ID: LXiZTu87Ck6
The patch also changes RemoteOpenFileChild::OpenNSPRFileDesc() so that it
cannot succeed with a null fd, so that checking just the return value is
sufficient.
This makes a lot of code more compact, and also avoids some redundant nsresult
checks.
The patch also removes a handful of redundant checks on infallible setters.
