searching for reviewer(mayhemer)
1f13810ca79e: Bug 1544089 - Allow the configuration of the ssltunnel listening address, r=mayhemer.
Bob Clary <bclary@bclary.com> - Wed, 17 Apr 2019 14:37:28 +0000 - rev 469885
Push 35884 by apavel@mozilla.com at Thu, 18 Apr 2019 21:35:00 +0000
Bug 1544089 - Allow the configuration of the ssltunnel listening address, r=mayhemer. Differential Revision: https://phabricator.services.mozilla.com/D27722
23a77e063257: Bug 1501108 - [1.3] Add GeckoView Session Context ID support. r=snorp,baku,mayhemer
Eugen Sawin <esawin@mozilla.com> - Tue, 16 Apr 2019 20:24:29 +0000 - rev 469860
Push 35883 by btara@mozilla.com at Wed, 17 Apr 2019 21:47:29 +0000
Bug 1501108 - [1.3] Add GeckoView Session Context ID support. r=snorp,baku,mayhemer Differential Revision: https://phabricator.services.mozilla.com/D19182
cad2b29b79d2: Bug 1501108 - [1.2] Add GeckoView Session Context ID support. r=snorp,baku,mayhemer
Eugen Sawin <esawin@mozilla.com> - Mon, 15 Apr 2019 20:58:30 +0000 - rev 469568
Push 35874 by ccoroiu@mozilla.com at Tue, 16 Apr 2019 04:04:58 +0000
Bug 1501108 - [1.2] Add GeckoView Session Context ID support. r=snorp,baku,mayhemer Differential Revision: https://phabricator.services.mozilla.com/D19182
aad1c782f753: Bug 1542835 - Expose SSLChannelInfo.resumed on nsISSLSocketControl, r=keeler,mayhemer
Michal Novotny <michal.novotny@gmail.com> - Sat, 13 Apr 2019 09:58:00 +0000 - rev 469399
Push 35865 by apavel@mozilla.com at Sat, 13 Apr 2019 21:44:49 +0000
Bug 1542835 - Expose SSLChannelInfo.resumed on nsISSLSocketControl, r=keeler,mayhemer This patch adds resumed attribute to nsISSLSocketControl, which is needed in tests that check SSL resumption (e.g. bug 1500533). Differential Revision: https://phabricator.services.mozilla.com/D26597
1cf54b6a1c90: Bug 1541114 - Check mIPCOpen before sending messages r=mayhemer
Kershaw Chang <kershaw@mozilla.com> - Fri, 12 Apr 2019 05:04:22 +0000 - rev 469213
Push 35858 by shindli@mozilla.com at Fri, 12 Apr 2019 09:34:00 +0000
Bug 1541114 - Check mIPCOpen before sending messages r=mayhemer To avoid sending ipc messages after the ipc channel is closed, check |mIPCOpen| before sending messages. Differential Revision: https://phabricator.services.mozilla.com/D26089
557f1dbc18ca: Bug 1541238 - add pref to delay 3rd-party tracker; r=mayhemer
Liang-Heng Chen <xeonchen@gmail.com> - Fri, 05 Apr 2019 16:30:08 +0000 - rev 468269
Push 35826 by nerli@mozilla.com at Sat, 06 Apr 2019 21:48:00 +0000
Bug 1541238 - add pref to delay 3rd-party tracker; r=mayhemer Differential Revision: https://phabricator.services.mozilla.com/D26266
90bec8daf359: Bug 1541755 - Remove NSMODULE_DEFN in TestPACMan.cpp. r=mayhemer
Mike Hommey <mh+mozilla@glandium.org> - Fri, 05 Apr 2019 11:29:05 +0000 - rev 468256
Push 35824 by apavel@mozilla.com at Sat, 06 Apr 2019 10:57:50 +0000
Bug 1541755 - Remove NSMODULE_DEFN in TestPACMan.cpp. r=mayhemer The module is manually registered through the component manager in the gtest setup anyways. Differential Revision: https://phabricator.services.mozilla.com/D26063
f002275ecaca: Bug 1456005 - Set LOAD_DISABLE_TRR flag in CaptiveDetect.jsm r=mayhemer
Valentin Gosu <valentin.gosu@gmail.com> - Fri, 05 Apr 2019 12:08:57 +0000 - rev 468128
Push 35820 by btara@mozilla.com at Fri, 05 Apr 2019 16:17:46 +0000
Bug 1456005 - Set LOAD_DISABLE_TRR flag in CaptiveDetect.jsm r=mayhemer This is useful to prevent issues in TRR mode 2 when a captive portal redirect occurs via DNS. For example, if we are in an unlocked CP and in suddenly locks, we must make sure that we don't use a cached DNS entry from when the portal was unlocked. This is especially relevant in split horizon situations. This isn't useful in TRR mode 3, as the flag would just cause the resolution to fail. For that we need to add the captive portal URI to the TRR exclusion list. Differential Revision: https://phabricator.services.mozilla.com/D25619
a75b9d4e8408: Bug 1451890 - TRR: set wait-for-portal false r=mayhemer
Valentin Gosu <valentin.gosu@gmail.com> - Fri, 05 Apr 2019 11:33:11 +0000 - rev 468125
Push 35820 by btara@mozilla.com at Fri, 05 Apr 2019 16:17:46 +0000
Bug 1451890 - TRR: set wait-for-portal false r=mayhemer Differential Revision: https://phabricator.services.mozilla.com/D25553
9b129ff965d7: Bug 1411725 - have XHR responseURL use the final channel URL so the expected URLs for substituted protocols like web-extension: are returned; r=mayhemer
Thomas Wisniewski <twisniewski@mozilla.com> - Sun, 31 Mar 2019 01:31:12 +0000 - rev 466960
Push 35788 by btara@mozilla.com at Sun, 31 Mar 2019 08:58:22 +0000
Bug 1411725 - have XHR responseURL use the final channel URL so the expected URLs for substituted protocols like web-extension: are returned; r=mayhemer have XHR responseURL use the final channel URL so the expected URLs for substituted protocols like web-extension: are returned Differential Revision: https://phabricator.services.mozilla.com/D23811
cec67adbdbb6: Bug 1539208 - P1 - Return an error when the Reponse object is null'd; r=mayhemer
Tom Tung <shes050117@gmail.com> - Thu, 28 Mar 2019 15:27:49 +0000 - rev 466730
Push 35780 by opoprus@mozilla.com at Fri, 29 Mar 2019 21:53:01 +0000
Bug 1539208 - P1 - Return an error when the Reponse object is null'd; r=mayhemer Differential Revision: https://phabricator.services.mozilla.com/D25228
447f58b42b72: Bug 1539539 - Add main thread assertion and fix a clang warning r=mayhemer
Kershaw Chang <kershaw@mozilla.com> - Thu, 28 Mar 2019 15:03:46 +0000 - rev 466724
Push 35780 by opoprus@mozilla.com at Fri, 29 Mar 2019 21:53:01 +0000
Bug 1539539 - Add main thread assertion and fix a clang warning r=mayhemer The resultCallback at [1] should be always executed on main thread, so adding an assertion to enforce this. This patch also fixes a warning at [2]. This is about moving a const captured variable. [1] https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/netwerk/protocol/http/nsHttpChannel.cpp#551-558 [2] https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/netwerk/base/nsNetUtil.cpp#2808 Differential Revision: https://phabricator.services.mozilla.com/D25219
9e2dd8254c43: Bug 1533369 - Add content type to cache index, r=mayhemer
Michal Novotny <michal.novotny@gmail.com> - Wed, 27 Mar 2019 14:32:12 +0000 - rev 466370
Push 35768 by opoprus@mozilla.com at Thu, 28 Mar 2019 09:55:54 +0000
Bug 1533369 - Add content type to cache index, r=mayhemer This patch adds content-type to metadata in cache entry and it is then propagated down to the cache index. Differential Revision: https://phabricator.services.mozilla.com/D23504
64664ada91ee: Bug 1522412 - P3. Adopt nsIChannel.LOAD_BYPASS_URL_CLASSIFIER in the algorithm determining if we should classify a channel's URI. r=Ehsan,mayhemer
dlee <dlee@mozilla.com> - Mon, 25 Mar 2019 12:48:25 +0000 - rev 465926
Push 35755 by cbrindusan@mozilla.com at Tue, 26 Mar 2019 00:24:34 +0000
Bug 1522412 - P3. Adopt nsIChannel.LOAD_BYPASS_URL_CLASSIFIER in the algorithm determining if we should classify a channel's URI. r=Ehsan,mayhemer This patch uses the flag to exempt channels from classification, but it doesn't include the use cases of this flag. See Bug 1442496 for the list of the call sites should use this flag. Differential Revision: https://phabricator.services.mozilla.com/D22112
eb789cfccafc: Bug 1522412 - P1. Replace LOAD_CLASSIFY_URI flag with a heuristic algorithm. r=Ehsan,mayhemer
dlee <dlee@mozilla.com> - Mon, 25 Mar 2019 12:47:29 +0000 - rev 465924
Push 35755 by cbrindusan@mozilla.com at Tue, 26 Mar 2019 00:24:34 +0000
Bug 1522412 - P1. Replace LOAD_CLASSIFY_URI flag with a heuristic algorithm. r=Ehsan,mayhemer In this patch, we move from a model where URL classification is opt-in (by specifying LOAD_CLASSIFIER_URI) to a model where it is enforced by default unless a channel opts out or is deemed to be a critical channel based on simple heuristics. The heuristics exempt a channel from classification if it is triggered by system with an exception when it is a top level load. To ensure critical channels are never classified, we also exempt channels which are flagged as "BeConservative" (implemented in bug 1321783). Another load flag LOAD_BYPASS_URL_CLASSIFIER is also introduced for the same reason. Differential Revision: https://phabricator.services.mozilla.com/D22110
5dc08ac77984: Bug 1411725 - have XHR responseURL use the final channel URL so the expected URLs for substituted protocols like web-extension: are returned; r=mayhemer
Thomas Wisniewski <twisniewski@mozilla.com> - Thu, 21 Mar 2019 23:43:52 +0000 - rev 465564
Push 35744 by apavel@mozilla.com at Fri, 22 Mar 2019 16:44:08 +0000
Bug 1411725 - have XHR responseURL use the final channel URL so the expected URLs for substituted protocols like web-extension: are returned; r=mayhemer have XHR responseURL use the final channel URL so the expected URLs for substituted protocols like web-extension: are returned Differential Revision: https://phabricator.services.mozilla.com/D23811
5399bca472b1: Bug 1522412 - P3. Adopt nsIChannel.LOAD_BYPASS_URL_CLASSIFIER in the algorithm determining if we should classify a channel's URI. r=Ehsan,mayhemer
Dimi Lee <dlee@mozilla.com> - Thu, 21 Mar 2019 07:32:46 +0000 - rev 465374
Push 35738 by ccoroiu@mozilla.com at Thu, 21 Mar 2019 21:59:09 +0000
Bug 1522412 - P3. Adopt nsIChannel.LOAD_BYPASS_URL_CLASSIFIER in the algorithm determining if we should classify a channel's URI. r=Ehsan,mayhemer This patch uses the flag to exempt channels from classification, but it doesn't include the use cases of this flag. See Bug 1442496 for the list of the call sites should use this flag. Differential Revision: https://phabricator.services.mozilla.com/D22112
b80098d0a5c4: Bug 1522412 - P1. Replace LOAD_CLASSIFY_URI flag with a heuristic algorithm. r=Ehsan,mayhemer
Dimi Lee <dlee@mozilla.com> - Thu, 21 Mar 2019 07:29:48 +0000 - rev 465372
Push 35738 by ccoroiu@mozilla.com at Thu, 21 Mar 2019 21:59:09 +0000
Bug 1522412 - P1. Replace LOAD_CLASSIFY_URI flag with a heuristic algorithm. r=Ehsan,mayhemer In this patch, we move from a model where URL classification is opt-in (by specifying LOAD_CLASSIFIER_URI) to a model where it is enforced by default unless a channel opts out or is deemed to be a critical channel based on simple heuristics. The heuristics exempt a channel from classification if it is triggered by system with an exception when it is a top level load. To ensure critical channels are never classified, we also exempt channels which are flagged as "BeConservative" (implemented in bug 1321783). Another load flag LOAD_BYPASS_URL_CLASSIFIER is also introduced for the same reason. Differential Revision: https://phabricator.services.mozilla.com/D22110
70b9b6dbe5b8: Bug 1521729 - P2: Fix failure tests r=mayhemer
Kershaw Chang <kershaw@mozilla.com> - Mon, 18 Mar 2019 14:50:56 +0000 - rev 464834
Push 35727 by dvarga@mozilla.com at Tue, 19 Mar 2019 09:48:59 +0000
Bug 1521729 - P2: Fix failure tests r=mayhemer Due to the p1 patch, the first time we get the result back from NS_ShouldSecureUpgrade is always asynchronously. This means that the first http request could be completed slower than the http requests opened after the first one. There are some tests affected by this change, since these tests assume that http requests should be completed in the same order as these requests were created. This patch fixes the tests by introducing a new method in nsIHttpProtocolHandler. This method returns a promise and makes sure the HSTS data is ready to read synchronously when the promise is resolved. Once the HSTS is ready to read, the order of open/close channels will be the same. Differential Revision: https://phabricator.services.mozilla.com/D21683
917f02e20ab6: Bug 1521729 - P1: Support to get the result from NS_ShouldSecureUpgrade asynchronously r=mayhemer
Kershaw Chang <kershaw@mozilla.com> - Mon, 18 Mar 2019 15:48:21 +0000 - rev 464833
Push 35727 by dvarga@mozilla.com at Tue, 19 Mar 2019 09:48:59 +0000
Bug 1521729 - P1: Support to get the result from NS_ShouldSecureUpgrade asynchronously r=mayhemer 1. Make nsHttpChannel::OnBeforeConnect async. 2. There are two ways to get the result from NS_ShouldSecureUpgrade. One is getting the result synchronously from the input reference and the other is via the provided callback. Note that the callback is only used when the storage is not ready to read at startup. Differential Revision: https://phabricator.services.mozilla.com/D20191
7c663cf76b8d: Bug 1151815 - Remove expiration time from the cache index, r=mayhemer
Michal Novotny <michal.novotny@gmail.com> - Mon, 11 Mar 2019 14:29:34 +0000 - rev 463808
Push 35697 by opoprus@mozilla.com at Wed, 13 Mar 2019 16:13:53 +0000
Bug 1151815 - Remove expiration time from the cache index, r=mayhemer Differential Revision: https://phabricator.services.mozilla.com/D22499
a75985a8a086: Bug 1530691 - Ignore OnStartRequest/StopRequest/DataAvailable after HttpChannelChild::ActorDestroy(Deletion) is called r=mayhemer
Valentin Gosu <valentin.gosu@gmail.com> - Thu, 07 Mar 2019 20:59:56 +0000 - rev 463018
Push 35665 by shindli@mozilla.com at Fri, 08 Mar 2019 09:39:15 +0000
Bug 1530691 - Ignore OnStartRequest/StopRequest/DataAvailable after HttpChannelChild::ActorDestroy(Deletion) is called r=mayhemer Differential Revision: https://phabricator.services.mozilla.com/D21908
c33c24d21420: Bug 1527293 - Loading a large script transferred with Content-Range from cache returns empty file, r=mayhemer
Michal Novotny <michal.novotny@gmail.com> - Fri, 01 Mar 2019 13:04:36 +0000 - rev 462231
Push 35644 by aciure@mozilla.com at Mon, 04 Mar 2019 21:48:23 +0000
Bug 1527293 - Loading a large script transferred with Content-Range from cache returns empty file, r=mayhemer Differential Revision: https://phabricator.services.mozilla.com/D21403
99eceab65655: Bug 1528352: Logging improvements in nsUDPSocket, and handle negative returns from PR_RecvFrom properly. r=mayhemer
Byron Campen [:bwc] <docfaraday@gmail.com> - Thu, 28 Feb 2019 15:17:27 +0000 - rev 461949
Push 35634 by rmaries@mozilla.com at Sat, 02 Mar 2019 09:26:10 +0000
Bug 1528352: Logging improvements in nsUDPSocket, and handle negative returns from PR_RecvFrom properly. r=mayhemer Differential Revision: https://phabricator.services.mozilla.com/D20565
d158405da514: Bug 1528352: Logging improvements in nsUDPSocket, and handle negative returns from PR_RecvFrom properly. r=mayhemer
Byron Campen [:bwc] <docfaraday@gmail.com> - Wed, 27 Feb 2019 15:39:57 +0000 - rev 461539
Push 35625 by csabou@mozilla.com at Thu, 28 Feb 2019 10:55:23 +0000
Bug 1528352: Logging improvements in nsUDPSocket, and handle negative returns from PR_RecvFrom properly. r=mayhemer Differential Revision: https://phabricator.services.mozilla.com/D20565
7bffd747d54a: Bug 1415508 - use Span in constructing a byte input stream; r=mayhemer
Alex Gaynor <agaynor@mozilla.com> - Mon, 25 Feb 2019 19:11:20 +0000 - rev 460956
Push 35613 by nerli@mozilla.com at Tue, 26 Feb 2019 03:52:35 +0000
Bug 1415508 - use Span in constructing a byte input stream; r=mayhemer Differential Revision: https://phabricator.services.mozilla.com/D20687
54102692d385: Bug 1522137 - Make resource://android return a nsIJARURI. r=snorp,mayhemer,bzbarsky
Agi Sferro <agi@mozilla.com> - Mon, 25 Feb 2019 15:38:33 +0000 - rev 460919
Push 35613 by nerli@mozilla.com at Tue, 26 Feb 2019 03:52:35 +0000
Bug 1522137 - Make resource://android return a nsIJARURI. r=snorp,mayhemer,bzbarsky resource://android URIs always point to a "jar:" URI so it doesn't make sense that the returned URL object implements nsIFileURL. This also makes it so extensions can be loaded from a resource://android URI. Audited all places where we use `nsIJARURI` and check for places where we assume it looks like `jar:`: the only (!) place where we do that is here: https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/dom/xhr/XMLHttpRequestMainThread.cpp#1852 Where we have special handling for `jar:` URIs. It looks like we would have less special handling for such a request to a `resource://android` and it could be fixed by just checking for the interface instead, but that's what's already happening today so it should work. That code is never reached for `resource://android` URIs as `mIsMappedArrayBuffer` is false for those URIs (see #2822). And the code is consistent in checking for the scheme instead of the interface (the other check is here: https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/dom/xhr/XMLHttpRequestMainThread.cpp#2822) Audited all places where we do `EqualsLiteral("jar")`: https://searchfox.org/mozilla-central/search?q=.EqualsLiteral%28%22jar%22%29&path= `SubstituteRemoteChannel`: looks interesting, but uses `nsISubstitutingProtocolHandler::ResolveURI` to first get the real URI (which is a `jar:`) so it works for our case. https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/netwerk/protocol/res/ExtensionProtocolHandler.cpp#414 `SubstitutingProtocolHandler.cpp` This case is explicitly fixed by this change, making it account for both `"jar"` and `"resource"`. https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/netwerk/protocol/res/SubstitutingProtocolHandler.cpp#299 `ReadSourceFromFileName`: this also looks interesting, but uses the channel to get the URI which returns the real `"jar"` URI and not the mapped `"resource"`. https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/js/xpconnect/src/XPCJSRuntime.cpp#2837 `nsStringBundle.cpp` Accounts for both `"jar"` and `"resource"`, so it should work the same. https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/intl/strres/nsStringBundle.cpp#437 Audited all places where we use `nsINestedURI` to make sure they would work for a `nsIJARURI` which does not implement `nsINestedURI`. `BrowserContentHandler.jsm` Uses `nsINestedURI` to figure out if a URI is local or not and then it checks whether it's a `"file"`, `"resource"` or `"chrome"` URI, for a `nsIJARURI & nsINestedURI` it would return a `"file"` which passes the test, for a `nsIJARURI` alone it would return `"resource"` which is also considered local by this code, so the result wouldn't change. https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/browser/components/BrowserContentHandler.jsm#395-399 `nsScriptSecurityManager.cpp` `GetOriginFromURI`: This is the reason why `SubstitutingJARURI` doesn't implement `nsINestedURI`, the origin is computed starting from the innermost URI, which in our case would be a file. The behavior in our case is that the origin from a `resource://android` URI behaves like other `resource://` URIs, which is what we expect. https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/caps/nsScriptSecurityManager.cpp#169 `CheckLoadURIWithPrincipal`: for `nsIJARURI & nsINestedURI` this code will only allow pages from the same jar to be in the same origin (which is correct), for `nsIJARURI` this code is unreachable and it would allow every `resource://android` to load every other `resource://android` URI (which is essentially the same thing). https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/caps/nsScriptSecurityManager.cpp#874-876 `nsDocShell.cpp` `DisplayLoadError`: Just looping through the nested URI chain to build an error message, no concerns here (it would just ignore the `jar:` part, which is fine). https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/docshell/base/nsDocShell.cpp#3986 `DoURILoad`: Looking for `view-source`, no concerns for `resource://android`. https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/docshell/base/nsDocShell.cpp#9645 `nsObjectLoadingContent.cpp` Also looking for `view-source`, no concerns. https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/dom/base/nsObjectLoadingContent.cpp#2004 `nsIconURI.cpp`/`nsIconURI.h` Exposing `nsINestedURI`. No concerns. https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/image/decoders/icon/nsIconURI.cpp#58 `nsJARURI.cpp`/`nsJARURI.h` Exposing `nsINestedURI`, the subject of this audit. https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/modules/libjar/nsJARURI.cpp#45 `nsIOService.cpp` `URIChainHasFlags`: This code looks at the chain of nested URIs to figure out if the chain of protocols has a certain flags. for `nsIJARURI & nsINestedURI` it would look at both `jar:` and `file:` protocols, while in `nsIJARURI` it would only look at the `resource:` protocol, which is our intention, since we want this URI to be treated like a `resource:` URI and nothing else. Note the `resource:` URI is always local (enforced by `NewURI`), so this should be ok. https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/netwerk/base/nsIOService.cpp#1494 `nsNetUtil.cpp`/`nsNetUtil.h` Implementation of `NS_ImplGetInnermostURI`, which wouldn't work for `nsIJARURI` alone, as expected. https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/netwerk/base/nsNetUtil.h#704 `nsSimpleNestedURI.cpp`/`nsSimpleNestedURI.h` Implementing `nsINestedURI` for `nsSimpleNestedURI`, no concerns. https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/netwerk/base/nsSimpleNestedURI.cpp#19 `nsViewSourceHandler.cpp` Looking at `view-source` inner URI to get the flags, no concerns. https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/netwerk/protocol/viewsource/nsViewSourceHandler.cpp#49 `nsHtml5StreamParser.cpp`/`nsHtml5TreeOpExecutor.cpp` More `view-source` handling code. No concerns. https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/parser/html/nsHtml5StreamParser.cpp#310 https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/parser/html/nsHtml5TreeOpExecutor.cpp#884 `DownloadPlatform.cpp` `IsURLPossiblyFromWeb`: This line is unreachable as the method would return true because resource has `URI_IS_UI_RESOURCE`. https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/toolkit/components/downloads/DownloadPlatform.cpp#314 `getAnonymizedPath`: This code looks a little scary, and it's the first one that seems to conflate the fact that `jar: == nsINestedURI`. On the android case (line 2130) this code manually replaces the `resource://android` URI with a `jar:` URI, so it wouldn't matter whether `resource://android` implements `nsINestedURI` or not. Actually this code could be a lot easier by using `nsISubstitutingURL::resolveURI`, maybe I should open a bug. https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/toolkit/components/search/SearchService.jsm#2148 `getRemoteTypeForURIObject`: This also looks interesting. The switch at line 157 would go straight to line 218 for `resource:` URIs (irrespective of `nsINestedURI`) and then for `nsINestedURI` we would look at the `jar:` URI (and eventually the `file:` URI). While for not `nsINestedURI` we would call straight to `validatedWebRemoteType`. This might return `WEB_REMOTE_TYPE` instead of `FILE_REMOTE_TYPE`, but since it's already happening it should be ok (`resource://android` maps _today_ to a `jar:` file that return `WEB_RETURN_TYPE`) https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/toolkit/modules/E10SUtils.jsm#150 `getURIHost`: This is another piece of code that benefits from not implementing `nsINestedURI` as the host would be correctly `"android"` instead of the apk path. https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/toolkit/mozapps/downloads/DownloadUtils.jsm#390 `initDialog`: Download dialog would show the `resource://android` URI instead of the actual `jar:` URI, kind of expected. https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/toolkit/mozapps/downloads/HelperAppDlg.jsm#423 There are no places in the codebase where we do `== "jar"`. Looks like I've already looked at all hits for "jar" too. Checked for `"jar:` too and It looks like they are all from code that tries to build a `jar:` URI manually which is fine for this change. Audited all `schemeIs("jar")` occurrences: https://searchfox.org/mozilla-central/search?q=schemeIs(%22jar%22)&path= `browser-identity.js` Uses the channel URI which is always resolved to `jar:`, so that works regardless. See also: https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/netwerk/protocol/res/SubstitutingProtocolHandler.cpp#229 https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/browser/base/content/browser-siteIdentity.js#812 `tabbrowser.js` Only for `scheme == "about"` URIs. https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/browser/base/content/tabbrowser.js#789 `HelperAppDialog.js` Treats "jar:" and "resource" the same way. https://searchfox.org/mozilla-central/rev/dc0adc07db3df9431a0876156f50c65d580010cb/mobile/android/components/HelperAppDialog.js#63 `WebNavigationContent.js` This code checks if the scheme is "jar" and if the original URI is "resource" it will use that instead, so in our case it will use the "resource" URI either way. https://searchfox.org/mozilla-central/rev/dc0adc07db3df9431a0876156f50c65d580010cb/toolkit/modules/addons/WebNavigationContent.js#158 Depends on D18740 Differential Revision: https://phabricator.services.mozilla.com/D16913
c79d6bd85dd8: Bug 1522137 - Move resource://android handler to C++. r=mayhemer
Agi Sferro <agi@mozilla.com> - Mon, 25 Feb 2019 15:38:21 +0000 - rev 460918
Push 35613 by nerli@mozilla.com at Tue, 26 Feb 2019 03:52:35 +0000
Bug 1522137 - Move resource://android handler to C++. r=mayhemer This is needed to make the handler to avoid race conditions where some code tries to access a resource://android URI before the handler has been registered. Depends on D18739 Differential Revision: https://phabricator.services.mozilla.com/D18740
78d3e59ea9fa: Bug 1507110 - Allow hijacking localhost only if network.proxy.allow_hijacking_localhost is set r=Gijs,mayhemer,mkaply,jmaher
Junior Hsu <juhsu@mozilla.com> - Tue, 19 Feb 2019 21:53:22 +0000 - rev 460278
Push 35590 by rgurzau@mozilla.com at Fri, 22 Feb 2019 05:26:22 +0000
Bug 1507110 - Allow hijacking localhost only if network.proxy.allow_hijacking_localhost is set r=Gijs,mayhemer,mkaply,jmaher Differential Revision: https://phabricator.services.mozilla.com/D19325
d5bafd3c816e: Bug 1528814: Serialize Loadinfo for PExternalHelperApp. r=mayhemer
Christoph Kerschbaumer <ckerschb@christophkerschbaumer.com> - Mon, 18 Feb 2019 18:11:22 +0100 - rev 459895
Push 35579 by dvarga@mozilla.com at Tue, 19 Feb 2019 21:39:51 +0000
Bug 1528814: Serialize Loadinfo for PExternalHelperApp. r=mayhemer
bc1a5ca9464b: Bug 1528188 - Get the HttpChannelParentListener via the parent r=mayhemer
Valentin Gosu <valentin.gosu@gmail.com> - Mon, 18 Feb 2019 21:37:44 +0000 - rev 459812
Push 35574 by cbrindusan@mozilla.com at Tue, 19 Feb 2019 04:38:09 +0000
Bug 1528188 - Get the HttpChannelParentListener via the parent r=mayhemer Differential Revision: https://phabricator.services.mozilla.com/D20184
2299664d9a0b: Bug 1528188 - Add test with blocking webRequest which overwrites notificationCallbacks r=mayhemer
Valentin Gosu <valentin.gosu@gmail.com> - Mon, 18 Feb 2019 21:37:30 +0000 - rev 459811
Push 35574 by cbrindusan@mozilla.com at Tue, 19 Feb 2019 04:38:09 +0000
Bug 1528188 - Add test with blocking webRequest which overwrites notificationCallbacks r=mayhemer Differential Revision: https://phabricator.services.mozilla.com/D20183
a7dc0e4d0136: Bug 1521808 - Add xpcshell-test for CrossOriginOpenerPolicy r=mayhemer,nika,annevk
Valentin Gosu <valentin.gosu@gmail.com> - Fri, 15 Feb 2019 22:02:52 +0000 - rev 459617
Push 35563 by ccoroiu@mozilla.com at Sat, 16 Feb 2019 09:36:04 +0000
Bug 1521808 - Add xpcshell-test for CrossOriginOpenerPolicy r=mayhemer,nika,annevk Differential Revision: https://phabricator.services.mozilla.com/D18246
6c7b1d562420: Bug 1521808 - Use topWindowPrincipal for CrossOriginOpenerPolicy check r=mayhemer,nika
Valentin Gosu <valentin.gosu@gmail.com> - Fri, 15 Feb 2019 22:28:56 +0000 - rev 459616
Push 35563 by ccoroiu@mozilla.com at Sat, 16 Feb 2019 09:36:04 +0000
Bug 1521808 - Use topWindowPrincipal for CrossOriginOpenerPolicy check r=mayhemer,nika - Adds nsIHttpChannelInternal.setTopWindowPrincipal used to pass the principal from the child to the parent Differential Revision: https://phabricator.services.mozilla.com/D18391
acf942062ea0: Bug 1521808 - Implement Cross-Origin-Opener-Policy header r=nika,mayhemer
Valentin Gosu <valentin.gosu@gmail.com> - Fri, 15 Feb 2019 22:02:58 +0000 - rev 459615
Push 35563 by ccoroiu@mozilla.com at Sat, 16 Feb 2019 09:36:04 +0000
Bug 1521808 - Implement Cross-Origin-Opener-Policy header r=nika,mayhemer Differential Revision: https://phabricator.services.mozilla.com/D18119
32ce09b2c33a: Bug 1521808 - Add xpcshell-test for CrossOriginOpenerPolicy r=mayhemer,nika,annevk
Valentin Gosu <valentin.gosu@gmail.com> - Fri, 15 Feb 2019 12:15:01 +0000 - rev 459425
Push 35561 by csabou@mozilla.com at Fri, 15 Feb 2019 18:37:54 +0000
Bug 1521808 - Add xpcshell-test for CrossOriginOpenerPolicy r=mayhemer,nika,annevk Differential Revision: https://phabricator.services.mozilla.com/D18246
94e513102b53: Bug 1521808 - Use topWindowPrincipal for CrossOriginOpenerPolicy check r=mayhemer,nika
Valentin Gosu <valentin.gosu@gmail.com> - Fri, 15 Feb 2019 12:15:21 +0000 - rev 459424
Push 35561 by csabou@mozilla.com at Fri, 15 Feb 2019 18:37:54 +0000
Bug 1521808 - Use topWindowPrincipal for CrossOriginOpenerPolicy check r=mayhemer,nika - Adds nsIHttpChannelInternal.setTopWindowPrincipal used to pass the principal from the child to the parent Differential Revision: https://phabricator.services.mozilla.com/D18391
a08553c07886: Bug 1521808 - Implement Cross-Origin-Opener-Policy header r=nika,mayhemer
Valentin Gosu <valentin.gosu@gmail.com> - Fri, 15 Feb 2019 12:15:39 +0000 - rev 459423
Push 35561 by csabou@mozilla.com at Fri, 15 Feb 2019 18:37:54 +0000
Bug 1521808 - Implement Cross-Origin-Opener-Policy header r=nika,mayhemer Differential Revision: https://phabricator.services.mozilla.com/D18119
890618032e65: Bug 1525900 - Remove unused code from old cache. r=mayhemer
Michal Novotny <michal.novotny@gmail.com> - Thu, 07 Feb 2019 05:49:00 +0200 - rev 459036
Push 35555 by rgurzau@mozilla.com at Thu, 14 Feb 2019 17:02:25 +0000
Bug 1525900 - Remove unused code from old cache. r=mayhemer
56f7fee6d139: Bug 1517601, part 3 - WebSocketEvent subclasses should not hold strong references to the channel. r=mayhemer
Andrew McCreight <continuation@gmail.com> - Wed, 13 Feb 2019 16:58:31 +0000 - rev 458931
Push 35551 by shindli@mozilla.com at Wed, 13 Feb 2019 21:34:09 +0000
Bug 1517601, part 3 - WebSocketEvent subclasses should not hold strong references to the channel. r=mayhemer This patch moves the channel pointer from the WebSocketEvents into the classes that wrap them (EventTargetDispatcher and WrappedWebSocketEvent) to fix leaks. EventTargetDispatcher uses a weak pointer. This is needed to prevent a leak if the ChannelEvent dispatch fails, because it would create a cycle of strong references between the WebSocketEvent, the channel, the channel event queue, and EventTargetDispatcher. It is safe because the ChannelEventQueue ensures that the channel remains alive. WrappedWebSocketEvent uses a strong pointer. This won't create a leak because the runnable is not owned by the channel. It is needed for safety because it can't rely on the ChannelEventQueue mechanism for keeping the channel alive. The WPT whitelisting moves them into two subdirectories that still seem to leak sometimes, but the top level websockets/ directory seems okay now. Depends on D19586 Differential Revision: https://phabricator.services.mozilla.com/D19587
57206fca017d: Bug 1517601, part 2 - Create and use a new WebSocketEvent base class instead of ChannelEvent. r=mayhemer
Andrew McCreight <continuation@gmail.com> - Wed, 13 Feb 2019 16:57:58 +0000 - rev 458930
Push 35551 by shindli@mozilla.com at Wed, 13 Feb 2019 21:34:09 +0000
Bug 1517601, part 2 - Create and use a new WebSocketEvent base class instead of ChannelEvent. r=mayhemer In the next patch, I want to change the signature of Run(), so I need to create a new base class for these inner WebSocket events. For now, this class is the same as ChannelEvent, except that it does not have the GetEventTarget method, which is never called. Depends on D19585 Differential Revision: https://phabricator.services.mozilla.com/D19586
8f6fc796dca2: Bug 1517601, part 1 - Remove the unused WebSocketChannelChild::DispatchToTargetThread() method. r=mayhemer
Andrew McCreight <continuation@gmail.com> - Wed, 13 Feb 2019 16:49:26 +0000 - rev 458929
Push 35551 by shindli@mozilla.com at Wed, 13 Feb 2019 21:34:09 +0000
Bug 1517601, part 1 - Remove the unused WebSocketChannelChild::DispatchToTargetThread() method. r=mayhemer Later patches change the WrappedChannelEvent ctor, so I'm removing this unused method to avoid having to fix it up. Differential Revision: https://phabricator.services.mozilla.com/D19585
c8c151d92c03: Bug 1521808 - Add xpcshell-test for CrossOriginOpenerPolicy r=mayhemer,nika,annevk
Valentin Gosu <valentin.gosu@gmail.com> - Tue, 12 Feb 2019 12:16:28 +0000 - rev 458672
Push 35543 by ccoroiu@mozilla.com at Tue, 12 Feb 2019 16:27:27 +0000
Bug 1521808 - Add xpcshell-test for CrossOriginOpenerPolicy r=mayhemer,nika,annevk Differential Revision: https://phabricator.services.mozilla.com/D18246
cc0a5c7dabb4: Bug 1521808 - Use topWindowPrincipal for CrossOriginOpenerPolicy check r=mayhemer,nika
Valentin Gosu <valentin.gosu@gmail.com> - Tue, 12 Feb 2019 12:16:16 +0000 - rev 458671
Push 35543 by ccoroiu@mozilla.com at Tue, 12 Feb 2019 16:27:27 +0000
Bug 1521808 - Use topWindowPrincipal for CrossOriginOpenerPolicy check r=mayhemer,nika - Adds nsIHttpChannelInternal.setTopWindowPrincipal used to pass the principal from the child to the parent Differential Revision: https://phabricator.services.mozilla.com/D18391
8d5174a560fa: Bug 1521808 - Implement Cross-Origin-Opener-Policy header r=nika,mayhemer
Valentin Gosu <valentin.gosu@gmail.com> - Tue, 12 Feb 2019 12:15:54 +0000 - rev 458670
Push 35543 by ccoroiu@mozilla.com at Tue, 12 Feb 2019 16:27:27 +0000
Bug 1521808 - Implement Cross-Origin-Opener-Policy header r=nika,mayhemer Differential Revision: https://phabricator.services.mozilla.com/D18119
de51545099a6: Bug 1522786 - Remove unused class member mHasQueryString r=mayhemer
Kershaw Chang <kershaw@mozilla.com> - Wed, 06 Feb 2019 18:16:59 +0000 - rev 457449
Push 35510 by rgurzau@mozilla.com at Wed, 06 Feb 2019 21:55:51 +0000
Bug 1522786 - Remove unused class member mHasQueryString r=mayhemer Simply remove unused class member mHasQueryString and HasQueryString() method. Differential Revision: https://phabricator.services.mozilla.com/D18694
83f419699bf1: Bug 1451293 - single thread access to ConnectionHandle::mConn r=mayhemer
Kershaw Chang <kershaw@mozilla.com> - Mon, 04 Feb 2019 08:42:09 +0000 - rev 456602
Push 35496 by btara@mozilla.com at Mon, 04 Feb 2019 17:36:40 +0000
Bug 1451293 - single thread access to ConnectionHandle::mConn r=mayhemer The goal of this patch is to make sure single thread access to ConnectionHandle::mConn. It contains: - Remove nsHttpTransaction::GetConnectionReference() - For the cases where we need the sticky connection, save the reference of the sticky connection's transaction instead. Then, the sticky connection will be extracted in socket thread and set it to the new transaction. Differential Revision: https://phabricator.services.mozilla.com/D17221
4a36400ab63c: Bug 1478124: Part 8d - Update netwerk module to use a static component manifest. r=mayhemer
Kris Maglione <maglione.k@gmail.com> - Sun, 16 Dec 2018 18:36:32 -0800 - rev 456007
Push 35466 by shindli@mozilla.com at Wed, 30 Jan 2019 04:11:39 +0000
Bug 1478124: Part 8d - Update netwerk module to use a static component manifest. r=mayhemer Differential Revision: https://phabricator.services.mozilla.com/D15042
496aaf774697: Bug 1478124: Part 8d - Update netwerk module to use a static component manifest. r=mayhemer
Kris Maglione <maglione.k@gmail.com> - Sun, 16 Dec 2018 18:36:32 -0800 - rev 455931
Push 35463 by shindli@mozilla.com at Tue, 29 Jan 2019 21:38:17 +0000
Bug 1478124: Part 8d - Update netwerk module to use a static component manifest. r=mayhemer Differential Revision: https://phabricator.services.mozilla.com/D15042
780eec2d27c3: Bug 1455723 - Firefox59 does not properly honor cache size set in autoconfig files, r=mayhemer
Michal Novotny <michal.novotny> - Mon, 14 Jan 2019 06:47:00 +0200 - rev 455786
Push 35458 by csabou@mozilla.com at Tue, 29 Jan 2019 10:03:06 +0000
Bug 1455723 - Firefox59 does not properly honor cache size set in autoconfig files, r=mayhemer We keep old cache code in the tree only because of offline cache. We no longer allow using old disk or memory cache. This patch removes all preferences manipulation from old cache code that isn't used by offline cache. It removes also some related code (e.g. everything smart size related, unused defines etc.), but the goal wasn't to remove all unused code from the old cache.