It currently isn't possible to suspend a channel from onHeadersReceived for a
cached response. And since it's not possible to add a new stream filter after
a response has started, adding a stream filter at that point will crash if the
channel is still registered.
This test is a basic sanity check for that scenario.
MozReview-Commit-ID: ALYUtxX7mci
We're currently fairly vague and inconsistent about the values we provide to
content policy implementations for requestOrigin and requestPrincipal. In some
cases they're the triggering principal, sometimes the loading principal,
sometimes the channel principal.
Our existing content policy implementations which require or expect a loading
principal currently retrieve it from the context node. Since no current
callers require the principal to be the loading principal, and some already
expect it to be the triggering principal (which there's currently no other way
to retrieve), I chose to pass the triggering principal whenever possible, but
use the loading principal to determine the origin URL.
As a follow-up, I'd like to change the nsIContentPolicy interface to
explicitly receive loading and triggering principals, or possibly just
LoadInfo instances, rather than poorly-defined request
origin/principal/context args. But since that may cause trouble for
comm-central, I'd rather not do it as part of this bug.
MozReview-Commit-ID: LqD9GxdzMte
Moving the event type lists to constants avoids array construction overhead
for each event, and allows us to use the much faster Set.has rather than
Array.includes.
Using Object.create to add the base request info to the listener-specific info
allows us to avoid object copy overhead.
Switching to a .forEach() loop lets us avoid creating expensive live Map
iterator objects, and also GC pressure caused by the huge number of iterator
result objects and intermediate array objects created by for-of-entries().
It's otherwise just as fast as for-of in Ion.
MozReview-Commit-ID: 53Fw1tJbuMY
We don't use the initial Map returned by ChannelWrapper as a map, so there's no
need for the overhead involved in creating it. We also don't need the header map
generated by HeaderChanger unless headers are actually being modified, which
for many listeners they never are, so there's no need for the map creation and
string lower-casing overhead prior to modification time.
MozReview-Commit-ID: K2uK93Oo542
This allows us to reuse the same URLInfo objects for each permission or
extension that we match, and also avoids a lot of XPConnect overhead we wind
up incurring when we access URI objects from the JS side.
MozReview-Commit-ID: GqgVRjQ3wYQ
Aside from moving this logic closer to the place the input data is generated,
this significantly reduces the number of cross-compartment wrappers involved
in creating those messages, especially with JSM global sharing enabled.
MozReview-Commit-ID: 6IvetcHnMfC
Ehsan, can you please review the (trivial) WebIDL changes, and Shane the
WebRequest logic?
The change to allow strings in MatchPattern arguments removes a huge amount of
XPConnect overhead that accumulates when creating nsIURI objects for
WebRequest processing.
The change to re-use existing URI objects removes a huge amount of URI
creation overhead.
MozReview-Commit-ID: 3DJjAKJK1Sa
This is the second step to migrating the policy service to pure native code,
with similar impacts and reasoning to the previous patch.
MozReview-Commit-ID: L5XdPzWNZXM
