This patch includes changes below:
1. Make nsBaseChannel inherit from NeckoTargetHolder.
2. Change FtpChannelChild due to (1) and also don't use SystemGroup to dispatch nsFtpChildAsyncAlert runnable since nsIPrompt may touch js script.
3. Use NeckoTargetHolder::Dispatch to dispatch runnables in nsBaseChannel.
Note that RedirectRunnable should be on main thread, so I changed the code from NS_DispatchToCurrentThread to NeckoTargetHolder::Dispatch.
It's silly to use prmem.h within Firefox code given that in our configuration
its functions are just wrappers for malloc() et al. (Indeed, in some places we
mix PR_Malloc() with free(), or malloc() with PR_Free().)
This patch removes all uses, except for the places where we need to use
PR_Free() to free something allocated by another NSPR function; in those cases
I've added a comment explaining which function did the allocation.
--HG--
extra : rebase_source : 0f781bca68b5bf3c4c191e09e277dfc8becffa09
This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
--HG--
extra : rebase_source : 318d1bc6fc1425a94aacbf489dd46e4f83211de4
All the instances are converted as follows.
- nsSubstring --> nsAString
- nsCSubstring --> nsACString
--HG--
extra : rebase_source : cfd2238c52e3cb4d13e3bd5ddb80ba6584ab6d91
All the instances are converted as follows.
- nsAFlatString --> nsString
- nsAFlatCString --> nsCString
--HG--
extra : rebase_source : b37350642c58a85a08363df2e7c610873faa6e41
All the instances are converted as follows.
- nsASingleFragmentString --> nsAString
- nsASingleFragmentCString --> nsACString
--HG--
extra : rebase_source : e6a1ddc8938fecd9a735b15e872c054edf4c7910
Move the initialization of nsUrlClassifierDBService to prior of calling ShouldEnableTrackingProtection(), so the nsUrlClassifierDBService will be initialized before staring HTTP connection. If not doing so, there is a 3.x% peformance regression on android platforam.
Add a field to the HSTS cache which indicates the source of the HSTS
entry if known, from the preload list, organically seen header, or HSTS
priming, or unknown otherwise. Also adds telemetry to collect the source
when upgrading in NS_ShouldSecureUpgrade.
MozReview-Commit-ID: 3IwyYe3Cn73
--HG--
extra : rebase_source : 9b8daac3aa02bd7a1b4285fb1e5731a817a76b7f
This patch includes two changes:
1. 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.
2. Skip channel annotation for first-party and top-level load http channels
--HG--
extra : rebase_source : 78f98f8200d3dbb1cb96cd0a33901b2a82227974
Collect telemetry for all requests to get an exact percentage of
requests that are subject to HSTS priming, and how many result in an
HSTS Priming request being sent. Clean up telemetry to remove instances
of double counting requests if a priming request was sent.
HSTSPrimingListener::ReportTiming was using mCallback to calculate
timing telemetry, but we were calling swap() on the nsCOMPtr. Give it an
explicit argument for the callback.
Add tests for telemetry values to all of the HSTS priming tests. This
tests for the minimum as telemetry may be gathered on background or
other requests.
MozReview-Commit-ID: 5V2Nf0Ugc3r
--HG--
extra : rebase_source : daa357219a77d912a78b95a703430f39d884c6ab
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
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
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
See bug 1365483 for the rationale.
MozReview-Commit-ID: 4sWodnP5MYZ
--HG--
extra : rebase_source : 6a32073e50695ac8f4a540c83f9d2b5542b53585
extra : intermediate-source : 5d7189453d82844d55e3d90c79792b2edd7bdd0d
extra : source : 8b029c32f3512c9d8e92582312459a501594a6e8
Originally the pref is called security.data_uri.inherit_security_context, so the pref is default on.
And when we finish this feature, we turn it off.
To avoid causing confusion in the future, perhaps we should rename it and make the pref default off.
This function is arguably nicer than calling NS_ProcessNextEvent
manually, is slightly more efficient, and will enable better auditing
for NS_ProcessNextEvent when we do Quantum DOM scheduling changes.
We now have code that unconditionally requires the rust
compiler and are committed to adding more. Remove this
last vestige of conditional support.
MozReview-Commit-ID: EK6FBnAbR
--HG--
extra : rebase_source : 6efda10a74f9ca0482304c2b1ffe6941e42138f8
Since the mTargetThread in nsInputStreamPump is directly acquired from current or main thread, we need to pass another labeled main thread target to dispatch runnables to the correct tab/doc group.
There's one redudant NS_ShouldCheckAppCache(nsIURI*, bool) is not used
anymore. Also we remove the extra usePrivateBrowsing argument, since we
can get this information from nsIPrincipal.
Currently nsBufferedInputStream is able to Fill() data only from sync
inputStream. When a page uses XHR to upload something, it creates a
nsBufferedInputStream around the source inputStream. This stream can be a
IPCBlobInputStream, and in that case, the reading is only supported using
nsIAsyncInputStream interface. nsBufferedInputStream must support it.
Some protocol handlers don't handle speculative connections too well
(they crash). So, we limit to the most useful protocols. This patch
brought to you by
https://bugzilla.mozilla.org/show_bug.cgi?id=1348278#c21
MozReview-Commit-ID: 8dWGdVtalIS
--HG--
extra : rebase_source : 9ba674282e40d8313fdb8fbd2f1b9ae7567d299d
This change makes the code a little cleaner and reduces the number of
places we call PR_GetCurrentThread, which is important for Quantum DOM
scheduling work.
The conversion was largely automatic, via:
find netwerk/ -name \*.cpp | \
xargs sed -i -e 's/MOZ_ASSERT(PR_GetCurrentThread() == gSocketThread[^;]*/MOZ_ASSERT(OnSocketThread(), "not on socket thread")/'
and related invocations, with a few manual tweaks at the end.
nsInputStreamPump should use the stream as nsIAsyncInputStream if available.
In order to do so, we need to wrap a BufferedStream around it.
MediaResource cannot use a simple sync nsIInputStream when BlobURL are involved
in the content process.
Serializing and sending IPC messages takes a lot of time, and it gets in the way of image loading. Making this functionality async gets out of the way of image loading (among other things).
The test has been changed to pump the main thread after calling predictor.learn so the multiprocess version can actually run to completion. This isn't strictly necessary in the single process version, but it makes the code changes (which are already pretty invasive) simpler.
MozReview-Commit-ID: 7jvhomlygbf
--HG--
extra : rebase_source : a779a498f83a2b02d2d634eff63d15f483793046
the protocol proxy service asserts that is in a clean state at dtor -
normally this happens through observe("xpcom-shutdown") but its
actually possible of other events in the xpcom run queue to
'unitialize' things before the dtor.. add a state in which fail codes
are returned instead.
MozReview-Commit-ID: XaNQEZUsRP
--HG--
extra : rebase_source : 054b01269d36dd8e8e24056f389c94a0d9183436
nsInputStreamPump should use the stream as nsIAsyncInputStream if available.
In order to do so, we need to wrap a BufferedStream around it.
MediaResource cannot use a simple sync nsIInputStream when BlobURL are involved
in the content process.
Everything depending on the widget being gonk can go away, as well as
everything depending on MOZ_AUDIO_CHANNEL_MANAGER, which was only
defined on gonk builds under b2g/ (which goes away in bug 1357326).
--HG--
extra : rebase_source : 9f0aeeb7eea8417fa4e06d662d566d67ecaf2a24
We will cache all preferences which will be read during classifing channel
- Store them into static variables nsUrlClassifierDBService
- Use a singleton class to manage/update preferrences in nsChannelClassifier
MozReview-Commit-ID: GvyBI3rVpYh
--HG--
extra : rebase_source : 0cec0724bd47f55c7b1666e700d172698a708efb
In the past we used a fixed value for the firstPartyDomain of
NullPrincipal, now we derive it from the path of NullPrincipal, so it
will be unique everytime we create it.
This helper class allows us to create simple channels that open an underlying
input stream when the channel is first opened, using a closure function,
without having to expose the nsBaseChannel class to non-necko code.
MozReview-Commit-ID: 6jiImdMXUp0
--HG--
extra : rebase_source : b8d30a28593940c41109b1352eb0c549213c5f89
Several of our simple channel implementations work naturally with direct
nsIStreamListener output. Currently, these implementations need to create a
pipe, pump data in to that pipe, and then allow nsBaseChannel to pump data out
of the other side of that pipe, into its own stream listener.
This change allows them to output data directly to nsBaseChannel's stream
listener, which removes unnecessary complexity and overhead.
MozReview-Commit-ID: JCGKTt6Kn9x
--HG--
extra : rebase_source : 200dd2641bfa703f658c2c5171a68df3a035be0a
Catalin Badea
Sylvestre Ledru
Sebastian Hengst
Michal Novotny
Kershaw Chang
Wes Kocher
Dragana Damjanovic dd.mozilla@gmail.com
Nicholas Nethercote
Dragana Damjanovic
Carsten "Tomcat" Book
Bill McCloskey
Masatoshi Kimura
DimiL
Shih-Chiang Chien
Liang-Heng Chen
Valentin Gosu
Ben
Honza Bambas
Kate McKinley
Jan Keromnes
Jan de Mooij
Boris Zbarsky
Bevis Tseng
Ryan VanderMeulen
Ben Kelly
Yoshi Huang
Ehsan Akhgari
Nicolas B. Pierron
Henri Sivonen
Thomas Nguyen
Felipe Gomes
Michael Kaply
JW Wang
John Schoenick
Edouard Oger
Nathan Froyd
Patrick McManus
Milan Sreckovic
Ralph Giles
Andi-Bogdan Postelnicu
Michael Layzell
Iris Hsiao
Andrea Marchesini
Nicholas Hurley
Jon Coppeard
Johann Hofmann
dOn'tReallycAre
Tom Tung
Mike Hommey
Ho-Pang Hsu
Kris Maglione