Use the new API addition to Document portal allowing clients to get real
path to the exported document. This allows to still use the same path as
provided by the document portal, but display the path as exists on the
host side.
Differential Revision: https://phabricator.services.mozilla.com/D202717
This patch:
* adds some simple logic to settings search that should prevent us from having to manually allow searching in every moz- prefixed custom element
* cleans up the existing settings search logic slightly for improved readability
* expands the tests to check searching for text in the shadow DOM of additional moz- prefixed custom elements
Differential Revision: https://phabricator.services.mozilla.com/D214141
The enrollmentHelper was much more complicated than it needed to be. The
internal asynchrony that required awaiting an additional promise was fixed in
bug 1773583.
The returned cleanup function is no longer async, so unnecessary awaits have
been removed. This also applies to enrollWithFeatureConfig, as it is a wrapper
around enrollmentHelper.
Differential Revision: https://phabricator.services.mozilla.com/D212318
Co-author/investigator: Tim Giles <tgiles@mozilla.com>
Delay sychronous loading of ESM based custom elements until the
DOMContentLoaded event. With D212190--which this patch depends on--the
components that have already been used on the page will be synchronously
loaded when customElements.setElementCreationCallback is registered.
Differential Revision: https://phabricator.services.mozilla.com/D212191
This also avoids sending an engine-update Glean event for the default engine by not handling the engine-icon-update
notification in the update tracking code.
Differential Revision: https://phabricator.services.mozilla.com/D210838
Initially reported and discussed in Bug 610896.
The simple solution of just flipping the pref `network.proxy.socks_remote_dns`
is risky due to potentially breaking SOCKS4 proxy users. Proxying
DNS on SOCKS4 isn't supported. Therefore we speak the incompatible
SOCKS4a protocol when `socks_remote_dns` is enabled, potentially
breaking users setup.
To keep backwards compatibility on SOCKS4 proxy users, that don't have
SOCKS4a support, the pref `network.proxy.socks_remote_dns` is split into
two prefs:
* `network.proxy.socks_remote_dns`: remote DNS for SOCKS4
* `network.proxy.socks5_remote_dns`: remote DNS for SOCKS5.
This way we proxy DNS by default on SOCKS5 while keeping user settings
on SOCKS4. This is a similar approach to the one described in
[Bug 610896 comment 17].
Proxying DNS in SOCKS4 by default is desireable (See [Bug 610896 comment 11]),
but out of scope for this patch. [Telemetry] on proxy usage by socks
version indicated that changing the default for SOCKS4 is likely break
some users setup and needs to be taken with more care.
The default values of [proxyDNS] now defaults to true for SOCKS5 proxies.
When creating nsIProxyInfo objects of SOCKS4 proxies, the default value
false is kept. Setting proxyDNS affects both SOCKS4 and SOCKS5 proxy by
modifying both `socks_remote_dns` and `socks5_remote_dns`. Therefore no
extension breakage is expected.
The enterprise policy can also modify the new pref
`network.proxy.socks5_remote_dns`.
Follow up bugs filed while implementing:
* Bug 1890542 - Also disable Prefetch non-manual configurations of socks
proxy
* Bug 1890554 - Use `ProxyInfo::TRANSPARENT_PROXY_RESOLVES_HOST` flag in
`nsHttpChannel::GetProxyDNSStrategy`
* Bug 1890549 - nsHttpChannel implementation DNS resolve strategy for
proxies incomplete
* Bug 1893670 - Proxy DNS by default for SOCK4 proxies. Defaulting to
SOCKS4a
[Bug 610896 comment 17]: https://bugzilla.mozilla.org/show_bug.cgi?id=610896#c17
[Bug 610896 comment 11]: https://bugzilla.mozilla.org/show_bug.cgi?id=610896#c11
[Telemetry]: https://bugzilla.mozilla.org/show_bug.cgi?id=1741375#c27
[proxyDNS]: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/proxy/settings#proxydns
Differential Revision: https://phabricator.services.mozilla.com/D207532
A number of changes are made as part of this patch:
- A consistent way of initializing update is created. This is automatically run when methods that need it are invoked.
- The "post-update-processing" notification has been removed. Post update processing is now done through the new `nsIApplicationUpdateService.init` or `nsIApplicationUpdateService.internal.postUpdateProcessing`.
- Post update processing no longer waits for the sessionstore-windows-restored observer service notification
- Post update processing is no longer invoked only when the `update.status` file exists. It is now run unconditionally.
- Explicitly initialize before we potentially clean up updates from the update UI.
Note that the update service stub and a few consumers of it ought to be able to wait for post update processing to be done but they currently do not. That will be done later in this patch stack when we rework the stub.
Differential Revision: https://phabricator.services.mozilla.com/D209126
Aside from tests (which will be in the next patch in the stack), this specifically leaves two instances of readyUpdate unchanged - the one in BrowserContentHandler's `getArgs` and the one in UpdatePing's `_getActiveUpdate`. In both of these cases what is actually wanted is the update that was just installed. It's only because of the (fairly arbitrary) order that things are started up in that `readyUpdate` still happens to contain this value when these things run. Later in this patch stack we will add something more appropriate for this. But in the meantime, it doesn't make sense to convert functions to be asynchronous that will not ultimately need to be asynchronous.
Differential Revision: https://phabricator.services.mozilla.com/D209115
A number of changes are made as part of this patch:
- A consistent way of initializing update is created. This is automatically run when methods that need it are invoked.
- The "post-update-processing" notification has been removed. Post update processing is now done through the new `nsIApplicationUpdateService.init` or `nsIApplicationUpdateService.internal.postUpdateProcessing`.
- Post update processing no longer waits for the sessionstore-windows-restored observer service notification
- Post update processing is no longer invoked only when the `update.status` file exists. It is now run unconditionally.
- Explicitly initialize before we potentially clean up updates from the update UI.
Note that the update service stub and a few consumers of it ought to be able to wait for post update processing to be done but they currently do not. That will be done later in this patch stack when we rework the stub.
Differential Revision: https://phabricator.services.mozilla.com/D209126
Aside from tests (which will be in the next patch in the stack), this specifically leaves two instances of readyUpdate unchanged - the one in BrowserContentHandler's `getArgs` and the one in UpdatePing's `_getActiveUpdate`. In both of these cases what is actually wanted is the update that was just installed. It's only because of the (fairly arbitrary) order that things are started up in that `readyUpdate` still happens to contain this value when these things run. Later in this patch stack we will add something more appropriate for this. But in the meantime, it doesn't make sense to convert functions to be asynchronous that will not ultimately need to be asynchronous.
Differential Revision: https://phabricator.services.mozilla.com/D209115
