This moves the check for a non-http proxy from the socket transport callbacks in
nsHttpConnection to nsHttpChannel before the connection occurs.
MozReview-Commit-ID: CJIozDInXWz
"Gecko trail" is the term used by MDN [1] for the YYYMMDD build date in the UA string's "Gecko/" token. Build ID is a YYYYMMDDHHMMSS build timestamp. Use LEGACY_BUILD_ID to spoof navigator.buildID. Use LEGACY_UA_GECKO_TRAIL to construct the UA string.
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox
Differential Revision: https://phabricator.services.mozilla.com/D7983
--HG--
extra : rebase_source : e2a4d7579d419046f0bad6290078f9a652a770d8
extra : source : 8a26c8598528722a8920513c7fdfea40aefe0dbc
This fixes bug introduced by patch from bug 1337893. Serialized origin attributes suffix should be appended instead of rewriting the string.
--HG--
extra : rebase_source : a8ab785102e6e080f3038c1bd94f2b8b82404a55
The first QI is never used. The second one is the same as the one in
nsCOMPtr.h, so we should be able to call that instead, which can be
done simply by deleting the method. The motivation is that I'm
changing how do_QueryInterface works, and I'd like to avoid changing
this place given that it isn't actually needed.
Differential Revision: https://phabricator.services.mozilla.com/D7528
--HG--
extra : moz-landing-system : lando
Bug 356831 added a release assert that when performing WPAD the network.proxy.type pref is always 4 (PROXYCONFIG_WPAD).
However, when changing the pref, the runnable is scheduled to run before the PAC thread is shutdown, so it will see the pref that is not PROXYCONFIG_WPAD, while attempting to do WPAD. To avoid this situation, we simply exit early when we detect the wrong pref value.
Differential Revision: https://phabricator.services.mozilla.com/D7617
--HG--
extra : moz-landing-system : lando
refactor some code into the search service. This is necessary to
allow the searchservice to pull multiple locales or regions from a single
extension, based on data the searchservice maintains.
Differential Revision: https://phabricator.services.mozilla.com/D7632
--HG--
extra : moz-landing-system : lando
Previously, we had not put pushed streams in the priority tree, we just
let them be top-level items in the tree. With this change, we will put
them into the tree initially based on the priority of the associated
stream. The only exception is if the associated stream is either a
Leader or Urgent Start (in which case, we will turn the pushed streams
into followers).
Once the pushed stream is matched with a request generated by gecko,
that pushed stream will be re-prioritized based on the priority gecko
has for the request, just like a regular pulled stream.
This also allows us to re-prioritize pushed streams into the background
on tab switch (we assume that, before they are matched, they belong to
the same window as the associated stream).
Differential Revision: https://phabricator.services.mozilla.com/D7223
--HG--
extra : moz-landing-system : lando
Calls to do_QueryInterface to a base class can be replaced by a static
cast, which is faster.
Differential Revision: https://phabricator.services.mozilla.com/D7224
--HG--
extra : moz-landing-system : lando
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
There was an earlier fix to this, that fixed part of the issue, but that
fix was racy. In the case where the transaction was matched with the
pushed stream before the pushed stream received its END_STREAM, and the
response headers did not include a content-length, the transaction would
never notice that the data was done being sent. When that transaction
was necessary for the load event to fire, the page would get stuck in
the loading state until the user explicitly cancelled.
This new patch ensures that the transaction will notice the EOS by
making sure the pushed stream gets inserted into the list of push
streams with data in the case described above. (The previous patch,
which is still in the tree, is still necessary, but not sufficient, to
fix the issue.)
Differential Revision: https://phabricator.services.mozilla.com/D7298
--HG--
extra : moz-landing-system : lando
called if not explicitly requested by the user prefs
The author did not isolate and fix the cause of the assertion failure,
but put in further diagnostics.The author did not isolate and fix the cause of the assertion failure,
but put in further diagnostics.
* an additional assertion was put in on the main thread (which if
triggered would reveal the stack trace)
* in one place where a previously a failure to read the network.proxy.type pref
was ignored, execution of WPAD is now halted with a warning.
Besides these improved diagnostics, in nsPACMan::LoadPACFromURI where an
asynchronous call was made to nsPACMan::StartLoading *before* the preconditions
for this call are set up was changed to be the other way around. The author
suspects that the previous code may have led to race conditions when
LoadPACFromURI was not called from the main thread, although it is not obvious
that this would have caused such a crash.
Differential Revision: https://phabricator.services.mozilla.com/D5388
--HG--
extra : moz-landing-system : lando
The test used to assume that the load event didn't matter and so
the expected values had to be updated to match the new behavior.
A new "slowIFrame" test was added to capture what was previously
tested by the "badIFrame".
Differential Revision: https://phabricator.services.mozilla.com/D7031
--HG--
extra : moz-landing-system : lando
The templated version of Finalize is not needed, because the argument
being passed in is already an nsIURI, so the QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6862
--HG--
extra : moz-landing-system : lando
Split nsHostRecord into AddrHostRecord and TypeHostRecord for standard address dns queries and queries by-type.
Differential Revision: https://phabricator.services.mozilla.com/D6130
--HG--
extra : moz-landing-system : lando
This also removes the (afaict, unused) stub implementation from TabParent. The netwerk header
inclusions were necessary because those files included TabParent.h and through it,
nsISecureBrowserUI, but now TabParent.h no longer does that.
Differential Revision: https://phabricator.services.mozilla.com/D6829
--HG--
extra : moz-landing-system : lando
Previously, if script tried to set a cookie that matched a cookie we had
received via Set-Cookie that was labeled httponly, script would think
that cookie was properly set (even though it wasn't). This ensures that
script knows just enough about httponly cookies to prevent this
inconsistent view while avoiding leakages of the potentially-sensitive
cookie values.
Differential Revision: https://phabricator.services.mozilla.com/D5700
--HG--
extra : moz-landing-system : lando
Remove various calls to SetCapacity() that fall into various misuse categories:
1) Mistakenly believing that the caller should advice the string about zero
terminator.
2) Cases where a single append does the right computation on its own.
3) Calling SetCapacity() with a constant when the string is self-allocated
and could be an nsAuto[C]StringN and the string doesn't get passed on
in a way that could benefit from a heap-allocated buffer.
4) Calling SetCapacity() before assigning a shared buffer to the string.
5) Calling SetCapacity() before calling a function that will either calls
SetLength() anyway or calls Adopt().
MozReview-Commit-ID: IKjfl5gLmcD
Differential Revision: https://phabricator.services.mozilla.com/D4672
--HG--
extra : moz-landing-system : lando
Simply replace the nsCString with nsDependentCSubstring to avoid copying the data. In this way, we can also avoid the potential OOM crash.
Differential Revision: https://phabricator.services.mozilla.com/D6685
--HG--
extra : moz-landing-system : lando
Right now, pushed streams don't get put in the priority hierarchy
anyway, and with the code as it was, we were sending an illegal PRIORITY
frame for stream 0. This prevents that from happening. We should
probably think about putting pushed streams in the priority hierarchy at
some point.
Differential Revision: https://phabricator.services.mozilla.com/D6500
--HG--
extra : moz-landing-system : lando
Most of the times when we automatically create nsThread wrappers for threads
that don't already have them, we don't actually need the event targets, since
those threads don't run XPCOM event loops. Aside from wasting memory, actually
creating these event loops can lead to leaks if a thread tries to dispatch a
runnable to the queue which creates a reference cycle with the thread.
Not creating the event queues for threads that don't actually need them helps
avoid those foot guns, and also makes it easier to figure out which treads
actually run XPCOM event loops.
MozReview-Commit-ID: Arck4VQqdne
--HG--
extra : source : a03a61d6d724503c3b7c5e31fe32ced1f5d1c219
extra : intermediate-source : 5152af6ab3e399216ef6db8f060c257b2ffbd330
extra : histedit_source : ef06000344416e0919f536d5720fa979d2d29c66%2C4671676b613dc3e3ec762edf5d72a2ffbe6fca3f
Most of the times when we automatically create nsThread wrappers for threads
that don't already have them, we don't actually need the event targets, since
those threads don't run XPCOM event loops. Aside from wasting memory, actually
creating these event loops can lead to leaks if a thread tries to dispatch a
runnable to the queue which creates a reference cycle with the thread.
Not creating the event queues for threads that don't actually need them helps
avoid those foot guns, and also makes it easier to figure out which treads
actually run XPCOM event loops.
MozReview-Commit-ID: Arck4VQqdne
--HG--
extra : rebase_source : fcf8fa50e748c4b54c3bb1997575d9ffd4cbaae1
extra : source : a03a61d6d724503c3b7c5e31fe32ced1f5d1c219
This replaces the tunnel using a new nr_socket implementation. Proxy detection
code is still done in the peer connction. However, the result is only used to
detect a proxy. The result is unused. Address resolution is done by necko code
in the parent process. The new socket wraps a WebrtcProxyChannel which uses
necko to handle proxy negotiation. This has a happy side effect of enabling all
authentication modes that necko already supports for http proxies.
This adds a protocol for Necko to manage, WebrtcProxyChannel. This new protocol
serves as a pipe for a CONNECT tunnel. It is only used in WebRtc and not built
in no WebRtc builds.
--HG--
extra : rebase_source : a951841f95eaaa0562886cf76b405b01f1adf70e
extra : intermediate-source : 5c3da21957fc80b07188bc8a405437b858027a22
extra : source : 594a32883463ab051677ba06e22fa6d062b4b4a9
Necko does not allow for a CONNECT only request to happen. This adds a flag
to signal an http channel should only CONNECT if proxied. This flag can only be
set if an HTTPUpgrade handler has been assigned. As proposed by rfc7639, an
alpn header will be included in the CONNECT request. Its value is determined by
the upgrade protocol passed to HTTPUpgrade.
The flag is added as part of nsIHttpChannelInternal because it is dependent on
HTTPUpgrade. It exists as a capability flag since the channel's transaction
needs to know to complete after a successful CONNECT. Also the transaction's
connection needs to know to stop writing transaction data after it CONNECTs or
if there's no proxy, and to not tell the transaction to reset.
If an nsHttpChannel has this flag set then the upgrade handler will receive the
socket after the CONNECT succeeds without doing tls if https.
In order to support xpcshell-test for this change, nsHttpConnectionMgr does a
little check to see if HTTPUpgrade callback is in JavaScript. If it is then
the callback is invoked on the main thread.
--HG--
extra : rebase_source : 96cdfe0e1ffe2f7dad7d12c83c22be92d118195a
extra : intermediate-source : 70710e9bf3d98488485c3265ebdea09683a42a80
extra : source : 25b4b531c10c4b2dae416fd7d744a63a32fed7e5
Everything that goes in a PLDHashtable (and its derivatives, like
nsTHashtable) needs to inherit from PLDHashEntryHdr. But through a lack
of enforcement, copy constructors for these derived classes didn't
explicitly invoke the copy constructor for PLDHashEntryHdr (and the
compiler didn't invoke the copy constructor for us). Instead,
PLDHashTable explicitly copied around the bits that the copy constructor
would have.
The current setup has two problems:
1) Derived classes should be using move construction, not copy
construction, since anything that's shuffling hash table keys/entries
around will be using move construction.
2) Derived classes should take responsibility for transferring bits of
superclass state around, and not rely on something else to handle that.
The second point is not a huge problem for PLDHashTable (PLDHashTable
only has to copy PLDHashEntryHdr's bits in a single place), but future
hash table implementations that might move entries around more
aggressively would have to insert compensation code all over the
place. Additionally, if moving entries is implemented via memcpy (which
is quite common), PLDHashTable copying around bits *again* is
inefficient.
Let's fix all these problems in one go, by:
1) Explicitly declaring the set of constructors that PLDHashEntryHdr
implements (and does not implement). In particular, the copy
constructor is deleted, so any derived classes that attempt to make
themselves copyable will be detected at compile time: the compiler
will complain that the superclass type is not copyable.
This change on its own will result in many compiler errors, so...
2) Change any derived classes to implement move constructors instead of
copy constructors. Note that some of these move constructors are,
strictly speaking, unnecessary, since the relevant classes are moved
via memcpy in nsTHashtable and its derivatives.
This removes the rarely used and somewhat odd
`iterator& BeginWriting/EndWriting(iterator&)` functions that take an iterator
as an in/out param and then return it.
--HG--
extra : rebase_source : 92066f996595e9b7df9642813c08592cee47c630
This switches over the few remaining usages of the deprecated
BeginWriting/EndWriting(iterator&) functions to the more standard
BeginWriting/EndWriting() functions.
--HG--
extra : rebase_source : 3c54621d4921eb45157ec4edce0b693bdd7f02d5
nsIAssociatedContentSecurity and nsISecurityInfoProvider are unused as of
bug 832834, so this patch removes them.
Differential Revision: https://phabricator.services.mozilla.com/D5693
--HG--
extra : moz-landing-system : lando
In the current implmentation of CookieServiceChild::SetCookieString, pass a null channel will crash the child process. This is because we call aChannel->GetURI() without checking if aChannel is null.
However, set cookie with a null channel is possible in non-e10s mode. To make sure the behavior to be consistent in both non-e10s and e10s mode, we have to pass an empty URIParams in child process.
Differential Revision: https://phabricator.services.mozilla.com/D5432
--HG--
extra : moz-landing-system : lando
Move all fields of nsISSLStatus to nsITransportSecurityProvider
Remove nsISSLStatus interface and definition
Update all code and test references to nsISSLStatus
Maintain ability to read in older version of serialized nsISSLStatus. This
is verified with psm_DeserializeCert gtest.
Differential Revision: https://phabricator.services.mozilla.com/D3704
--HG--
extra : moz-landing-system : lando
> dom/media/gmp/CDMStorageIdProvider.cpp(63,10): warning:
> local variable 'storageId' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> layout/painting/DisplayItemClip.cpp(581,10): warning:
> local variable 'str' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> layout/painting/DisplayItemClipChain.cpp(88,10): warning:
> local variable 'str' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> layout/painting/nsDisplayList.cpp(179,10): warning:
> local variable 'str' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> gfx/thebes/gfxWindowsPlatform.cpp(454,10): warning:
> moving a local object in a return statement prevents copy elision [-Wpessimizing-move]
Will remove std::move().
> gfx/thebes/gfxFontEntry.cpp(245,20): warning:
> local variable 'name' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> netwerk/cookie/nsCookieService.cpp(4460,10): warning:
> local variable 'path' will be copied despite being returned by name [-Wreturn-std-move]
GetPathFromURI() result is stored in an nsAutoCString, so it might as well return that type.
> toolkit/components/extensions/WebExtensionPolicy.cpp(462,12): warning:
> local variable 'result' will be copied despite being returned by name [-Wreturn-std-move]
> toolkit/components/extensions/WebExtensionPolicy.cpp(475,10): warning:
> local variable 'result' will be copied despite being returned by name [-Wreturn-std-move]
`result` may be empty or may be arbitrarily long, so I'll use nsCString inside the function.
> toolkit/xre/CmdLineAndEnvUtils.h(349,10): warning:
> moving a local object in a return statement prevents copy elision [-Wpessimizing-move]
Returning an UniquePtr, will remove std::move().
Also will `return s` instead of `return nullptr` when `(!s)`, to avoid extra construction which could also prevent elision (not entirely sure, but it's at least not worse!); and it's clearer that the two `return`s return the same already-constructed on-stack object.
> tools/profiler/core/shared-libraries-win32.cc(111,10): warning:
> local variable 'version' will be copied despite being returned by name [-Wreturn-std-move]
nsPrintfCString -> nsCString, will add std::move().
> xpcom/glue/FileUtils.cpp(179,10): warning:
> local variable 'fullName' will be copied despite being returned by name [-Wreturn-std-move]
> xpcom/glue/FileUtils.cpp(209,10): warning:
> local variable 'path' will be copied despite being returned by name [-Wreturn-std-move]
nsAuto{,C}String -> ns{,C}String, will add std::move().
This allowed removals of 'AllowCompilerWarnings' from layout/painting,
netwerk/cookie, and toolkit/components/extensions.
Differential Revision: https://phabricator.services.mozilla.com/D5425
--HG--
extra : moz-landing-system : lando
Move all fields of nsISSLStatus to nsITransportSecurityProvider
Remove nsISSLStatus interface and definition
Update all code and test references to nsISSLStatus
Maintain ability to read in older version of serialized nsISSLStatus. This
is verified with psm_DeserializeCert gtest.
Differential Revision: https://phabricator.services.mozilla.com/D3704
--HG--
extra : moz-landing-system : lando
OnSocketTread doesn't work properly during shutdown because nsSocketTransportService2.cpp::gSocketThread is null.
We call gSocketTransportService->IsOnCurrentThreadInfallible() instead, just like we already do in HttpBackgroundChannelChild::ActorDestroy()
Differential Revision: https://phabricator.services.mozilla.com/D5050
--HG--
extra : moz-landing-system : lando
This patch builds the foundation for the ability to relocate HTTP channels from one content process to another in order to ensure that origins are properly isolated. This relocation would normally occur when the response to an HTTP request is a redirect to a different origin.
The patch merely adds the mechanism for relocating the channel, rather than the logic of doing so. This will be provided in a follow-up patch by a specialized service. Right now that functionality is mocked in the test.
How this works:
In nsHttpChannel::OnStartRequest we will query the service that decides whether we need to direct the response to another process. If so, it will return a promise that resolves to a TabParent.
When the promise resolves, in HttpChannelParentListener::TriggerCrossProcessRedirect we call NeckoParent::SendCrossProcessRedirect passing along the required information to recreate the channel in the new process. The NeckoChild in the new process will then instantiate a new channel, call ConnectParent() which creates the associated parent channel, and connects it with the existing nsHttpChannel.
A listener in the new process is then notified of the existence of the new channel. It is required to call completeRedirectSetup on the channel, passing an nsIStreamListener to the call.
We then finish the entire operation with a call to HttpChannelChild::SendCrossProcessRedirectDone which causes us to close the old HttpChannelChild in the previous process and to resume the nsHttpChannel in the main process.
Differential Revision: https://phabricator.services.mozilla.com/D2958
--HG--
rename : netwerk/test/browser/browser_cookie_sync_across_tabs.js => netwerk/test/browser/browser_cross_process_redirect.js
rename : dom/media/test/redirect.sjs => netwerk/test/browser/redirect.sjs
extra : moz-landing-system : lando
This patch builds the foundation for the ability to relocate HTTP channels from one content process to another in order to ensure that origins are properly isolated. This relocation would normally occur when the response to an HTTP request is a redirect to a different origin.
The patch merely adds the mechanism for relocating the channel, rather than the logic of doing so. This will be provided in a follow-up patch by a specialized service. Right now that functionality is mocked in the test.
How this works:
In nsHttpChannel::OnStartRequest we will query the service that decides whether we need to direct the response to another process. If so, it will return a promise that resolves to a TabParent.
When the promise resolves, in HttpChannelParentListener::TriggerCrossProcessRedirect we call NeckoParent::SendCrossProcessRedirect passing along the required information to recreate the channel in the new process. The NeckoChild in the new process will then instantiate a new channel, call ConnectParent() which creates the associated parent channel, and connects it with the existing nsHttpChannel.
A listener in the new process is then notified of the existence of the new channel. It is required to call completeRedirectSetup on the channel, passing an nsIStreamListener to the call.
We then finish the entire operation with a call to HttpChannelChild::SendCrossProcessRedirectDone which causes us to close the old HttpChannelChild in the previous process and to resume the nsHttpChannel in the main process.
Differential Revision: https://phabricator.services.mozilla.com/D2958
--HG--
rename : netwerk/test/browser/browser_cookie_sync_across_tabs.js => netwerk/test/browser/browser_cross_process_redirect.js
rename : dom/media/test/redirect.sjs => netwerk/test/browser/redirect.sjs
extra : moz-landing-system : lando
The fail log shows that the cookie's expiring time is too short(only 1s). The cookie could be already expired.
A simple solution in this patch is just extending the expiring time to 3s.
Differential Revision: https://phabricator.services.mozilla.com/D5034
--HG--
extra : moz-landing-system : lando
... since AF_INET wouldn't actually use IPv4!
MozReview-Commit-ID: FCf7psawENI
Differential Revision: https://phabricator.services.mozilla.com/D4749
--HG--
extra : moz-landing-system : lando
1. Add network.cookie.QuotaPerHost, which has the default value 150.
2. When the cookies exceed more than 180, evict cookies to 150.
3. The concept of eviction is to sort all cookies by whether the cookie is expired and the cookie's last access time. Then, evict cookies by the given count.
4. Details of evict algorithm:
4.1 Create a priority queue and push all cookies in it.
4.2 Use custom comparator to compare the cookie by expiry and last access.
4.3 Pop 30(180 - 150) cookies from the queue and append them to an output array.
Differential Revision: https://phabricator.services.mozilla.com/D3342
--HG--
extra : moz-landing-system : lando
Introduce these new blocking state values:
const unsigned long STATE_COOKIES_BLOCKED_BY_PERMISSION = 0x10000000;
const unsigned long STATE_COOKIES_BLOCKED_TRACKER = 0x20000000;
const unsigned long STATE_COOKIES_BLOCKED_ALL = 0x40000000;
const unsigned long STATE_COOKIES_BLOCKED_FOREIGN = 0x80000000;
make counter increased when trackers are found
Differential Revision: https://phabricator.services.mozilla.com/D4068
--HG--
extra : rebase_source : 90da79fbb83271b2f7a8460ebd02aa2abb635305
extra : source : c476aa79a8ca991dc8ea1e5c2eab98e442dad406
so that such requests don't inadvertently reuse connections done that
might have used TRR.
MozReview-Commit-ID: 2bO4VCGSgOO
Differential Revision: https://phabricator.services.mozilla.com/D4693
--HG--
extra : moz-landing-system : lando
In the current implmentation of CookieServiceChild::SetCookieString, pass a null channel will crash the child process. This is because we call aChannel->GetURI() without checking if aChannel is null.
However, set cookie with a null channel is possible in non-e10s mode. To make sure the behavior to be consistent in both non-e10s and e10s mode, we have to pass an empty URIParams in child process.
Differential Revision: https://phabricator.services.mozilla.com/D5432
--HG--
extra : rebase_source : 0d5b78130661fd02d9906e41f30c69ffdfca650b
We've introduced a new pref network.cookie.quotaPerHost and also a rule that the value of network.cookie.maxPerHost should always be bigger than network.cookie.quotaPerHost. So, before changing the value of network.cookie.maxPerHost, we have to set network.cookie.quotaPerHost first.
This patch only sets network.cookie.quotaPerHost equal to network.cookie.maxPerHost - 1 in all failed tests.
Differential Revision: https://phabricator.services.mozilla.com/D4346
--HG--
extra : moz-landing-system : lando
