The current channel annotation is happened at nsChannelClassifier::OnClassifyComplete and this is too late because this channel might be already hit the network.
This patch adds a new API CheckIsTrackerWithLocalTable in nsChannelClassifier to check if the URI is in local blacklist and whitelist before calling BeginConnectActual.
Please note that whitelist will be checked only when TP is disabled.
--HG--
extra : rebase_source : 0761f6c7631bc934691c8d018be88514568a3aa1
The original code creates nsChannelClassifier and calls ShouldEnableTrackingProtection twice when TP is enabled. To avoid redundancy, this patch makes channel classifier as a data member in nsHttpChannel. Note that the data member is a weak ptr to prevent ref count cycle.
--HG--
extra : rebase_source : 4a77f1e51b38e27a065162cc702091aca2db51de
Also removes some dead code.
A lot of the code in ExtensionUtils.jsm is not needed in all processes, and a
lot of the rest isn't needed until extension code runs. Most of it winds up
being loaded into all processes way earlier than necessary.
MozReview-Commit-ID: CMRjCPOjRF2
--HG--
extra : rebase_source : 37718eaf05a22b8ccb95f633cf7454bd7975cdce
This removes unnecessary COM overhead from the extension protocol service,
particularly from the flag lookup code, which is called often, and from hot
paths. The devirtualized lookups should have virtually no overhead for
extensions without web-accessible resources, and very little overhead except
when resources are specified as non-prefix globs.
MozReview-Commit-ID: 4hQ7GuQSjvW
--HG--
extra : rebase_source : 61897a204abd915ad61852fa475cde2de51753f3
NotifyTrackingProtectionDisabled/NotifyTrackingResource/SetClassifierMatchedInfo updates tracking protection and safe browsing states from parent to child.
They should at least handled by child process before OnStopRequest. Move them to PHttpBackgroundChannel can ensure that.
MozReview-Commit-ID: 8T6k9z9FgrI
--HG--
extra : rebase_source : fd26e2b4309a31e0a9bb16c9236eb4a1875518dc
OnStartRequestSent is used to ensure the execution order between OnStartRequest and all other messsages sent over PBackground.
IPC messages sent before OnStartRequestSent can be processed immediately while received by content process.
IPC messages sent after OnSartRequestSent need to be pending until OnStartRequestReceived is called.
MozReview-Commit-ID: 5Vbb8SBQmW8
--HG--
extra : rebase_source : 81ddce949d2a658e227e1e67d7d4313f7c66513f
PHttpBackgroundChannel is created by content process because PBackground IPDL
can only be initiated from content process. The background channel deletion is
controlled by chrome process while PHttpChannel is going to be closed or canceled.
BackgroundChannelRegistrar is introduced for pairing HttpChannelParent and
HttpBackgroundChannelParent since they are created over different IPDL
asynchronously.
nsIParentRedirectingChannel.continueVerification is introduced to asynchronously
wait for background channel to be established on the new channel during the
Redirect2Verify phase.
MozReview-Commit-ID: 41l8ivan8iA
--HG--
extra : rebase_source : b8b6d7e7c037efaa9fc13df14191205c603e833a
AsyncOpen procedure can failed and trigger FailedAsyncOpen IPC to do the clean up.
However FailedAsyncOpen might not complete if content process is destroyed at the meantime.
We can delay the timing of holding the strong reference to parent listener and channel object
to make sure no reference cycle is created by HttpChannelParent. In addition, clean up the
strong reference as soon as FailedAsyncOpen IPC is triggered.
MozReview-Commit-ID: LDOt0BpBgFe
--HG--
extra : rebase_source : 38e1128e8c361a2422ec4d8292b591ab3b3ef41f
PHttpBackgroundChannel is introduced to deliver OnStopRequest/OnTransportAndData/OnProgress/OnStatus on background thread.
FlushedForDiversion/DivertMessages is moved to PHttpBackgroundChannel to ensure no more channel event are delivered after these two messages on the background channel.
OnStartRequestSent is introduced to synchronize the execution order between OnStartRequest (main thread IPC) and all other messages on PHttpBackgroundChannel.
MozReview-Commit-ID: HfqvPML6EKw
--HG--
extra : rebase_source : 423709763e1abf1362347bc2d3141e2d33aed46a
When the last request is removed from the load group, we report telemetry for the default load request. This was done without checking if the request was successful, which may cause us to report telemetry for failed requests as well.
Also, the NullHttpChannel had its timingEnabled attribute set to true, which could lead us to report invalid telemetry
MozReview-Commit-ID: 5w7rd2V17Xd
--HG--
extra : rebase_source : 60785ebc38da8880aa6ded668fed8af81c3d60e9
We write a lot of 4-bytes prefixes to file which call many system calls.
We should use a buffer and only write to file if the buffer is full or
finish writing. nsIBufferedOutputStream is a good candidate to do that
MozReview-Commit-ID: CzGOd7iXVTv
--HG--
extra : rebase_source : 25f1ce804b9a53e0a0a4023a1aa91f1a0ed98547
In order to provide more details context of how client arrived at the unsafe
page, particularly in redirect case, we may have to add more information to
redirect chains including:
- referrer (if any)
- remote address.
- URL
We may want to use an idl interface instead of nsIPrincipal to store these
information
MozReview-Commit-ID: 3Uh4r06w60C
Wes Kocher
Ehsan Akhgari
Kershaw Chang
Nicolas B. Pierron
Kris Maglione
Sebastian Hengst
Jan de Mooij
Randell Jesup
Nils Ohlmeier [:drno]
Randall Barker
Liang-Heng Chen
Honza Bambas
Ryan VanderMeulen
Shih-Chiang Chien
Valentin Gosu
Thomas Nguyen
Dragana Damjanovic
Junior Hsu
Arthur Edelstein
Mike Hommey