This applies the following changes:
- store a weak reference to the browser element in the WebNavigation.jsm Manager's map
of pending CreatedNavigationTarget messages
- when a CreatedNavigationTarget message is received from a sourceTab
for a created window that is not currently tracked in the map
(e.g. it has been immediately closed), the message received from the sourceTab
is not saved in the map of the pending CreatedNavigationTarget (and a message
is logged in the console to make easier to investigate issues related to discarded
CreatedNavigationTarget events).
- adds an additional assertion to the related test case to ensure that no CreatedNavigationTarget
message is still pending in the WebNavigation/jsm's Manager.
MozReview-Commit-ID: FijQ8IqiY8L
--HG--
extra : rebase_source : cd3c072301a1eb24de368c655a96891dd1287c7b
This changes fixes the regression introduced by Bug 1355120 and adds a new
test case which contains a browserAction popup which open and immediately
close a new window and ensure that the received onCreatedNavigationTarget
is the expected one.
MozReview-Commit-ID: JIcVCpBTpxj
--HG--
extra : rebase_source : 37a7db29fa91d0e3f0593f7d5d996ccd3fba719d
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
--HG--
extra : rebase_source : 120889fd8f9edd097a7dae807b54eb3fd283f0f6
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
--HG--
extra : rebase_source : 41ce439912ae7b895e0a3b0e660fa6ba571eb50f
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
--HG--
extra : rebase_source : 7fd7095239fec790347d3febb8bf9af17fffc1af
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
--HG--
extra : rebase_source : f50574fb0eb32878aee3f68b3a73d46ba53987e5
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
--HG--
extra : rebase_source : 71c19fd8b432c16a3f13f7d0bd0424064f3e5661
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
--HG--
extra : rebase_source : 0f97464ee9840ac40a6882e70e99d5b6c566c5ef
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
--HG--
extra : rebase_source : 585a1c3c136ed1c5014f680ae81f635c8d1a2931
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
--HG--
extra : rebase_source : dda006a0afb9d56e2738dbc0b0d94ba0496db5c9
Luca Greco
Kris Maglione
Shane Caraveo
Wes Kocher
Ryan VanderMeulen
Sebastian Hengst
Masatoshi Kimura
Mark Banner
Andrew McCreight
Florian Quèze