Граф коммитов

212 Коммитов

Автор SHA1 Сообщение Дата
Jan Varga d730017508 Bug 1722668 - Expose nsFileStream via the component manager; r=necko-reviewers,dragana,jari
Differential Revision: https://phabricator.services.mozilla.com/D123773
2021-09-04 21:54:53 +00:00
Csoregi Natalia 03b44ad93d Backed out 3 changesets (bug 1722668) for failures on test_unsetLastAccessTime.js. CLOSED TREE
Backed out changeset db05822c64ff (bug 1722668)
Backed out changeset c9f100cb3f86 (bug 1722668)
Backed out changeset a7179b67eb1a (bug 1722668)
2021-09-05 00:22:49 +03:00
Jan Varga 1e06353298 Bug 1722668 - Expose nsFileStream via the component manager; r=necko-reviewers,dragana,jari
Differential Revision: https://phabricator.services.mozilla.com/D123773
2021-09-04 20:10:12 +00:00
Valentin Gosu 125e29a561 Bug 1694662 - Remove nsApplicationCacheService component r=necko-reviewers,kershaw
Differential Revision: https://phabricator.services.mozilla.com/D106452
2021-04-30 07:20:23 +00:00
Valentin Gosu ec5835855a Bug 1707036 - Remove nsFTPDirListingConv r=necko-reviewers,dragana
Differential Revision: https://phabricator.services.mozilla.com/D113788
2021-04-30 06:50:14 +00:00
Tom Tung 57e6375fc2 Bug 1696111 - Use sniffers in the requested category; r=necko-reviewers,valentin
After applying D102448,
uriloader/exthandler/tests/mochitest/test_nullCharFile.xhtml starts to fail.
The reason is that it adds image sniffer into net-content-sniffers which is not
expected.

Such that, this patch
- adds two other sniffers category:
  - orb-content-sniffers
    - The sniffers that are needed in ORB.
  - net-and-orb-content-sniffers
    - The sniffers that are in either orb-content-sniffers or net-content-sniffers.
- changes the way to ensure we only use the sniffers in the
requested category.

Differential Revision: https://phabricator.services.mozilla.com/D107207
2021-03-30 00:52:32 +00:00
Butkovits Atila ad9b1ed9d7 Backed out 12 changesets (bug 1683131, bug 1696111, bug 1695987) for causing crashes(Bug 1701151). a=backout
Backed out changeset 8ffef57e27d2 (bug 1683131)
Backed out changeset c02d5dc72abb (bug 1695987)
Backed out changeset 276f016ddc67 (bug 1683131)
Backed out changeset 2c7a45e20b50 (bug 1683131)
Backed out changeset 11fdb503d537 (bug 1696111)
Backed out changeset 2946eff1e9c8 (bug 1696111)
Backed out changeset e4d01b88e517 (bug 1696111)
Backed out changeset fab7f4cd445d (bug 1696111)
Backed out changeset d60c38f8939a (bug 1696111)
Backed out changeset 3fdc8089a46f (bug 1696111)
Backed out changeset 51a16dfabc98 (bug 1696111)
Backed out changeset 642bdd52fd57 (bug 1696111)
2021-03-26 11:30:28 +02:00
Tom Tung 02e26e0a82 Bug 1696111 - Use sniffers in the requested category; r=necko-reviewers,valentin
After applying D102448,
uriloader/exthandler/tests/mochitest/test_nullCharFile.xhtml starts to fail.
The reason is that it adds image sniffer into net-content-sniffers which is not
expected.

Such that, this patch
- adds two other sniffers category:
  - orb-content-sniffers
    - The sniffers that are needed in ORB.
  - net-and-orb-content-sniffers
    - The sniffers that are in either orb-content-sniffers or net-content-sniffers.
- changes the way to ensure we only use the sniffers in the
requested category.

Differential Revision: https://phabricator.services.mozilla.com/D107207
2021-03-25 12:09:41 +00:00
Christoph Kerschbaumer f5cd986818 Bug 1583044: Make nsMozIconURI serializeable. r=valentin
Differential Revision: https://phabricator.services.mozilla.com/D49442

--HG--
extra : moz-landing-system : lando
2019-10-21 14:16:49 +00:00
Razvan Maries f1b8926d68 Backed out changeset fb8fb91d2a96 (bug 1583044) for causing perma fails on test_DownloadUtils.js and reftests. CLOSED TREE 2019-10-18 15:25:07 +03:00
Christoph Kerschbaumer 89195abaf2 Bug 1583044: Make nsMozIconURI serializeable. r=valentin
Differential Revision: https://phabricator.services.mozilla.com/D49442

--HG--
extra : moz-landing-system : lando
2019-10-18 10:49:55 +00:00
Boris Zbarsky 9c5da5f234 Bug 1489308 part 9. Remove now-unused wyciwyg bits. r=mccr8
Differential Revision: https://phabricator.services.mozilla.com/D17327

--HG--
rename : dom/html/test/browser_refresh_wyciwyg_url.js => dom/html/test/browser_refresh_after_document_write.js
rename : dom/html/test/file_refresh_wyciwyg_url.html => dom/html/test/file_refresh_after_document_write.html
extra : moz-landing-system : lando
2019-02-28 01:09:48 +00:00
Jonathan Kingston f6680698bd Bug 1525319 - Removing context from OnDataAvailable r=valentin
Differential Revision: https://phabricator.services.mozilla.com/D20881

--HG--
extra : moz-landing-system : lando
2019-02-27 23:42:27 +00:00
Agi Sferro d6b900089c 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

--HG--
extra : moz-landing-system : lando
2019-02-25 15:38:33 +00:00
Ehsan Akhgari e5e885ae31 Bug 1521000 - Part 2: Adjust our clang-format rules to include spaces after the hash for nested preprocessor directives r=sylvestre
# ignore-this-changeset

--HG--
extra : amend_source : 7221c8d15a765df71171099468e7c7faa648f37c
extra : histedit_source : a0cce6015636202bff09e35a13f72e03257a7695
2019-01-18 10:16:18 +01:00
Tooru Fujisawa 7983faeb5d Bug 1511393 - Use c-basic-offset: 2 in Emacs mode line for C/C++ code. r=nbp 2018-12-01 04:52:05 +09:00
Sylvestre Ledru 265e672179 Bug 1511181 - Reformat everything to the Google coding style r=ehsan a=clang-format
# ignore-this-changeset

--HG--
extra : amend_source : 4d301d3b0b8711c4692392aa76088ba7fd7d1022
2018-11-30 11:46:48 +01:00
Valentin Gosu 3753105b42 Bug 1460537 - Connectivity Service - Add DNSv4 and DNSv6 checks r=dragana
Differential Revision: https://phabricator.services.mozilla.com/D7844

--HG--
extra : moz-landing-system : lando
2018-10-29 11:22:40 +00:00
Coroiu Cristina feba378b98 Backed out 2 changesets (bug 1460537) for xpcshell failures at netwerk/test/unit/test_network_connectivity_service.js on a CLOSED TREE
Backed out changeset ae2b0a2cd8a7 (bug 1460537)
Backed out changeset bd3f7151c697 (bug 1460537)
2018-10-25 20:16:10 +03:00
Valentin Gosu 23793b33e1 Bug 1460537 - Connectivity Service - Add DNSv4 and DNSv6 checks r=dragana
Differential Revision: https://phabricator.services.mozilla.com/D7844

--HG--
extra : moz-landing-system : lando
2018-10-25 15:48:51 +00:00
Ehsan Akhgari 488ca4192a Bug 1501404 - Part 8: Remove the XPCOM registration for NamedPipeService r=valentin
Depends on D9576

Differential Revision: https://phabricator.services.mozilla.com/D9577

--HG--
extra : moz-landing-system : lando
2018-10-23 20:07:31 +00:00
Ehsan Akhgari d0ee7e43f9 Bug 1501404 - Part 7: Remove the XPCOM registration for nsSyncStreamListener r=valentin
Depends on D9575

Differential Revision: https://phabricator.services.mozilla.com/D9576

--HG--
extra : moz-landing-system : lando
2018-10-23 20:07:29 +00:00
Ehsan Akhgari f6b7bc0052 Bug 1501404 - Part 6: Remove the XPCOM registrations for socket provider classes r=valentin
Depends on D9574

Differential Revision: https://phabricator.services.mozilla.com/D9575

--HG--
extra : moz-landing-system : lando
2018-10-23 20:07:27 +00:00
Ehsan Akhgari 229b1144b8 Bug 1501404 - Part 5: Remove the XPCOM registration for nsSocketProviderService r=valentin
Depends on D9573

Differential Revision: https://phabricator.services.mozilla.com/D9574

--HG--
extra : moz-landing-system : lando
2018-10-23 20:07:25 +00:00
Ehsan Akhgari 1c8e7af29d Bug 1501404 - Part 4: Remove the unused contract ID for nsIHttpPushListener r=valentin
Depends on D9572

Differential Revision: https://phabricator.services.mozilla.com/D9573

--HG--
extra : moz-landing-system : lando
2018-10-23 20:07:23 +00:00
Ehsan Akhgari c1fa5fcfa6 Bug 1501404 - Part 3: Remove the unused contract ID for nsIProxyAutoConfig r=valentin
Depends on D9571

Differential Revision: https://phabricator.services.mozilla.com/D9572

--HG--
extra : moz-landing-system : lando
2018-10-23 20:07:21 +00:00
Ehsan Akhgari 245edc5053 Bug 1501404 - Part 2: Remove the XPCOM registration for nsRequestObserverProxy r=valentin
Depends on D9570

Differential Revision: https://phabricator.services.mozilla.com/D9571

--HG--
extra : moz-landing-system : lando
2018-10-23 20:07:19 +00:00
Ehsan Akhgari e6c5cd6e52 Bug 1501404 - Part 1: Remove the XPCOM registration for RequestContextService r=valentin
Differential Revision: https://phabricator.services.mozilla.com/D9570

--HG--
extra : moz-landing-system : lando
2018-10-23 20:07:17 +00:00
Ehsan Akhgari 94133b9360 Bug 1488305 - Remove the XPCOM component registration for BackgroundChannelRegistrar r=nwgh
Differential Revision: https://phabricator.services.mozilla.com/D4893

--HG--
extra : moz-landing-system : lando
2018-09-26 00:27:32 +00:00
Ehsan Akhgari 645a5d3db1 Bug 1489916 - Remove the XPCOM component registration for nsHttpChannelAuthProvider; r=valentin
Differential Revision: https://phabricator.services.mozilla.com/D5390
2018-09-10 08:01:37 -04:00
Ehsan Akhgari 2dc43a81ad Bug 1489915 - Remove the XPCOM component registration for nsFileStream; r=valentin
Differential Revision: https://phabricator.services.mozilla.com/D5389
2018-09-10 08:00:44 -04:00
Ehsan Akhgari 5b13de3efe Backout changeset 9e6e20d26c0d (bug 1488305) because it hasn't been reviewed yet 2018-09-05 10:03:24 -04:00
Ehsan Akhgari 266b53e783 Bug 1488305 - Remove the XPCOM component registration for BackgroundChannelRegistrar; r=valentin
Differential Revision: https://phabricator.services.mozilla.com/D4893
2018-09-05 10:01:16 -04:00
Ehsan Akhgari d7274895ea Bug 1488306 - Remove the XPCOM component registration for nsUnknwonDecoder; r=valentin
Differential Revision: https://phabricator.services.mozilla.com/D4897
2018-09-04 09:43:52 -04:00
Ehsan Akhgari 9762248d38 Bug 1488236 - Remove the XPCOM component registration for nsApplicationCacheNamespace; r=valentin
Differential Revision: https://phabricator.services.mozilla.com/D4877
2018-09-03 14:28:40 -04:00
Ehsan Akhgari 92bbdcda2d Bug 1488238 - Remove the XPCOM component registration for nsApplicationCache; r=valentin
Differential Revision: https://phabricator.services.mozilla.com/D4878
2018-09-03 14:01:03 -04:00
Ehsan Akhgari 9172f9d616 Bug 1485494 - Remove the XPCOM registration for RedirectChannelRegistrar; r=mayhemer 2018-08-24 13:04:10 -04:00
Polly Shaw 226a5beff6 Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin
This patch addresses an issue with Firefox's proxy detection on networks which
do not have their a proxy auto-configuration (PAC) file hosted at
http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting
the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/
for an introduction to the protocol.

Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just
 looked for a PAC file at http://wpad/wpad.dat


This patch only addresses the issue for Firefox on Windows, although it defines a
DHCP client interface which could be implemented on other platforms.

The high-level components of this patch are:
 * nsIDHCPClient.idl - this is an interface which has been defined for querying the
   DHCP server.
 * nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of
   http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy
   thread. The class ExecutePACThreadAction has been augmented to include an
   instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class,
   'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC
   file) back to the nsPACMan object.
 * nsProtocolProxyService.cpp
   Minor changes to reflect the fact that the PAC URL not being set does not always
   mean there is no PAC to be used; instead it could be in the process of being
   detected.
 * TestPACMan.cpp
   This is a new file, and tests only the DHCP auto-detect functionality.
   Some tests use multiple threads, as they test the non-blocking proxy detection.
 * DHCPUtils.cpp
   A class containing the main logic for querying DHCP.
 * WindowsNetworkFunctionsWrapper.cpp
   A very thin wrapper around the Windows API calls needed by DHCPUtils.
   This class was introduced so it could be mocked out in tests.
 * nsWindowsDHCPClient.cpp
 * An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin:
   most logic is implemented in DHCPUtils.
 * TestDHCPUtils.cpp
   Tests for DHCPUtils and nsWindowsDHCPClient

MozReview-Commit-ID: 4xFQz3tOLEx

--HG--
extra : rebase_source : dfd5c588406a8b0d92f91cc8a0038ca722b7140a
2018-06-07 23:07:28 +01:00
Andreea Pavel 86dffac409 Backed out changeset a7a1006e2f52 (bug 356831) for braking marionette on win asan on a CLOSED TREE 2018-07-10 18:42:01 +03:00
Polly Shaw b18d1fbc4a Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin
This patch addresses an issue with Firefox's proxy detection on networks which
do not have their a proxy auto-configuration (PAC) file hosted at
http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting
the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/
for an introduction to the protocol.

Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just
 looked for a PAC file at http://wpad/wpad.dat


This patch only addresses the issue for Firefox on Windows, although it defines a
DHCP client interface which could be implemented on other platforms.

The high-level components of this patch are:
 * nsIDHCPClient.idl - this is an interface which has been defined for querying the
   DHCP server.
 * nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of
   http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy
   thread. The class ExecutePACThreadAction has been augmented to include an
   instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class,
   'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC
   file) back to the nsPACMan object.
 * nsProtocolProxyService.cpp
   Minor changes to reflect the fact that the PAC URL not being set does not always
   mean there is no PAC to be used; instead it could be in the process of being
   detected.
 * TestPACMan.cpp
   This is a new file, and tests only the DHCP auto-detect functionality.
   Some tests use multiple threads, as they test the non-blocking proxy detection.
 * DHCPUtils.cpp
   A class containing the main logic for querying DHCP.
 * WindowsNetworkFunctionsWrapper.cpp
   A very thin wrapper around the Windows API calls needed by DHCPUtils.
   This class was introduced so it could be mocked out in tests.
 * nsWindowsDHCPClient.cpp
 * An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin:
   most logic is implemented in DHCPUtils.
 * TestDHCPUtils.cpp
   Tests for DHCPUtils and nsWindowsDHCPClient

MozReview-Commit-ID: 4xFQz3tOLEx

--HG--
extra : rebase_source : 4fb364432625418acf743b67a2caadc5a92caf7c
2018-06-07 23:07:28 +01:00
Valentin Gosu 6a2d43d5e7 Bug 1456863 - Backed out bug 356831 (changeset 204bb43af943) for leaks r=me 2018-04-30 15:34:39 +02:00
Polly Shaw 091db15fe1 Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin
This patch addresses an issue with Firefox's proxy detection on networks which
do not have their a proxy auto-configuration (PAC) file hosted at
http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting
the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/
for an introduction to the protocol.

Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just
 looked for a PAC file at http://wpad/wpad.dat


This patch only addresses the issue for Firefox on Windows, although it defines a
DHCP client interface which could be implemented on other platforms.

The high-level components of this patch are:
 * nsIDHCPClient.idl - this is an interface which has been defined for querying the
   DHCP server.
 * nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of
   http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy
   thread. The class ExecutePACThreadAction has been augmented to include an
   instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class,
   'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC
   file) back to the nsPACMan object.
 * nsProtocolProxyService.cpp
   Minor changes to reflect the fact that the PAC URL not being set does not always
   mean there is no PAC to be used; instead it could be in the process of being
   detected.
 * TestPACMan.cpp
   This is a new file, and tests only the DHCP auto-detect functionality.
   Some tests use multiple threads, as they test the non-blocking proxy detection.
 * DHCPUtils.cpp
   A class containing the main logic for querying DHCP.
 * WindowsNetworkFunctionsWrapper.cpp
   A very thin wrapper around the Windows API calls needed by DHCPUtils.
   This class was introduced so it could be mocked out in tests.
 * nsWindowsDHCPClient.cpp
 * An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin:
   most logic is implemented in DHCPUtils.
 * TestDHCPUtils.cpp
   Tests for DHCPUtils and nsWindowsDHCPClient

MozReview-Commit-ID: HinC1UevOon

--HG--
extra : rebase_source : cf29f76826cc7728fd36505c8271bf50001c644c
2018-04-22 18:13:11 +01:00
Margareta Eliza Balazs 0fe561286b Backed out changeset 2a760b1c0759 (bug 356831) for adding files without having a bugzilla product and component 2018-04-24 19:33:00 +03:00
Polly Shaw f95f738f4e Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin
This patch addresses an issue with Firefox's proxy detection on networks which
do not have their a proxy auto-configuration (PAC) file hosted at
http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting
the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/
for an introduction to the protocol.

Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just
 looked for a PAC file at http://wpad/wpad.dat


This patch only addresses the issue for Firefox on Windows, although it defines a
DHCP client interface which could be implemented on other platforms.

The high-level components of this patch are:
 * nsIDHCPClient.idl - this is an interface which has been defined for querying the
   DHCP server.
 * nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of
   http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy
   thread. The class ExecutePACThreadAction has been augmented to include an
   instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class,
   'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC
   file) back to the nsPACMan object.
 * nsProtocolProxyService.cpp
   Minor changes to reflect the fact that the PAC URL not being set does not always
   mean there is no PAC to be used; instead it could be in the process of being
   detected.
 * TestPACMan.cpp
   This is a new file, and tests only the DHCP auto-detect functionality.
   Some tests use multiple threads, as they test the non-blocking proxy detection.
 * DHCPUtils.cpp
   A class containing the main logic for querying DHCP.
 * WindowsNetworkFunctionsWrapper.cpp
   A very thin wrapper around the Windows API calls needed by DHCPUtils.
   This class was introduced so it could be mocked out in tests.
 * nsWindowsDHCPClient.cpp
 * An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin:
   most logic is implemented in DHCPUtils.
 * TestDHCPUtils.cpp
   Tests for DHCPUtils and nsWindowsDHCPClient

MozReview-Commit-ID: HinC1UevOon

--HG--
extra : rebase_source : df2b80fcc03948e54f222e11060e1783f3b95421
2018-04-22 18:13:11 +01:00
Valentin Gosu eccc344c51 Bug 1442242 - Make the constuctors of URI implementations private r=mayhemer
MozReview-Commit-ID: LonNnZyJjVO

--HG--
extra : rebase_source : ceefc81a669b17f68f193fce5f172f9f2268a998
2018-03-20 23:23:31 +01:00
Noemi Erli 3e8b48fa31 Backed out 3 changesets (bug 1442242) for fatal error LNK1120: 1 unresolved externals bustages on a CLOSED TREE
Backed out changeset 9f37df3c62e1 (bug 1442242)
Backed out changeset 65b8727bfe76 (bug 1442242)
Backed out changeset 88130a542fb3 (bug 1442242)
2018-03-20 16:45:34 +02:00
Valentin Gosu 2d128cd0dd Bug 1442242 - Make the constuctors of URI implementations private r=mayhemer
MozReview-Commit-ID: 4oo66aYg66s

--HG--
extra : rebase_source : 9503ed13ad14f7df8eb1ac85b3a0eed14928173b
2018-03-20 12:52:50 +01:00
Valentin Gosu af5eeff2e3 Bug 1442239 - Make URI deserialization (nsISerializable.read) happen via nsIURIMutator only r=mayhemer
* Deserialization now only happens via a mutator
* The CID for URI implementations actually returns the nsIURIMutator for each class
* The QueryInterface of mutators implementing nsISerializable will now act as a finalizer if passed the IID of an interface implemented by the URI it holds

MozReview-Commit-ID: H5MUJOEkpia

--HG--
extra : rebase_source : 01c8d16f7d31977eda6ca061e7889cedbf6940c2
2018-03-19 20:22:32 +01:00
Andreea Pavel e5950c0d39 Backed out 2 changesets (bug 1442239) for xpcshell failures at widget/tests/unit/test_taskbar_jumplistitems.js on a CLOSED TREE
Backed out changeset 513cd669aca1 (bug 1442239)
Backed out changeset aef4c73f736f (bug 1442239)
2018-03-19 21:19:26 +02:00
Valentin Gosu f0c7a1ae13 Bug 1442239 - Make URI deserialization (nsISerializable.read) happen via nsIURIMutator only r=mayhemer
* Deserialization now only happens via a mutator
* The CID for URI implementations actually returns the nsIURIMutator for each class
* The QueryInterface of mutators implementing nsISerializable will now act as a finalizer if passed the IID of an interface implemented by the URI it holds

MozReview-Commit-ID: H5MUJOEkpia

--HG--
extra : rebase_source : 8ebb459445cab23288a6c4c86e4e00c6ee611e34
2018-03-08 13:35:10 +01:00