Since the RESOLVE_JAR_URI flag is not used for moz-extension, ResolveJARURI
would never get called in ExtensionProtocolHandler, so it's OK to consider
it threadsafe.
Differential Revision: https://phabricator.services.mozilla.com/D33253
Since we want themes to be loaded before the main browser window is loaded, we
really need their resources to be ready as soon as possible. We typically
delay serving moz-extension: requests until the extension is ready, since
extension page and CSS loads rely on the extension being fully initialized.
Image loads, though, are perfectly safe to load as early as we need, so this
patch whitelists them to bypass the delayed load logic.
We don't want extension protocol load requests to begin loading until the
extension is far enough initialized to run code. If we load it before then,
the extension framework will either fail to recognize the extension entirely,
or may begin running its scripts in an incomplete environment.
This patch adds a slow path which adds a promise handler and creats a stub
channel only in the case when the extension is not ready. In the normal,
already-initialized case, we take the more direct path.
Differential Revision: https://phabricator.services.mozilla.com/D21447
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Before this change, the trusted URI schemes, based on a string whitelist, were:
https, file, resource, app, moz-extension and wss.
This change removes "app" from the list (since we don't implement it),
and adds "about" to the list (because we control the delivery of that).
This patch was reviewed in parts, however the intermediate states would not build:
Bug 1443954 - Part 3A: Strip pointers from the argument to WriteParam and WriteIPDLParam before selecting the ParamTraits impl, r=froydnj
Bug 1443954 - Part 3B: Move nsIAlertNotification serialization to the refcounted system, r=bz
Bug 1443954 - Part 3C: Move geolocation serialization to the refcounted system, r=bz
Bug 1443954 - Part 3D: Move nsIInputStream serialization to the refcounted system, r=baku
Bug 1443954 - Part 3E: Move BlobImpl serialization to the refcounted system, r=baku
Bug 1443954 - Part 3F: Correctly implement ParamTraits for actors after the ParamTraits changes, r=froydnj
Currently if you write an async IPDL method which has a return value, we expose
a SendXXX method which returns a MozPromise. This MozPromise can then be
->Then-ed to run code when it is resolved or rejected.
Unfortunately, using this API loses ordering guarantees which IPDL provides.
MozPromise::Then takes an event target, which the resolve runnable is dispatched
to. This means that the resolve callback's code doesn't have any ordering
guarantees relative to the processing of other IPC messages coming over the same
protocol.
This adds a new overload to SendXXX with two additional arguments, a lambda
callback which is called if the call succeeds, and a lambda callback which is
called if the call fails. These will be called in order with other IPC messages
sent over the same protocol.
MozReview-Commit-ID: FZHJJaSDoZy
Add calls to OnStartRequest() and OnStopRequest() to properly handle async
read failures for remote JAR's and remote unpacked extension resources.
MozReview-Commit-ID: Dcg0LDht9B9
Fix circular dependency created when encountering a path to a nonexistent JAR
inner file.
Change cache JAR loads to not use ExtensionStreamGetter, instead call the JAR
channel's AsyncOpen2 method directly in the SimpleChannel callback.
Remove the code to handle cached JAR loads from ExtensionStreamGetter.
MozReview-Commit-ID: Kmry02eLYU1
Fix ExtensionProtocolHandler::GetAsync() to handle failures returned
from AsyncOpen2() for cached JAR resources.
Don't call SetupEventTarget() in the cached JAR ExtensionStreamGetter
constructor because the event target is not needed and calling
SetupEventTarget() triggers a debug mode warning from
nsContentUtils::GetEventTargetByLoadInfo().
MozReview-Commit-ID: KjDsPNQWlwU
Also adds a mozilla/ResultExtensions.h header to define the appropriate
conversion functions for nsresult and PRResult. This is in a separate header
since those types are not available in Spidermonkey, and this is the pattern
other *Extensions.h headers follow.
Also removes equivalent NS_TRY macros and WrapNSResult inlines that served the
same purpose in existing code, and are no longer necessary.
MozReview-Commit-ID: A85PCAeyWhx
This allows MOZ_TRY and MOZ_TRY_VAR to be transparently used in XPCOM methods
when compatible Result types are used.
Also removes a compatibility macro in SimpleChannel.cpp, and an identical
specialization in AddonManagerStartup, which are no longer necessary after
this change.
MozReview-Commit-ID: 94iNrPDJEnN
