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
Stop supporting following the system preference, but keep macOS users
able to switch to just text controls (accessibility.tabfocus=1) in the
settings.
Change the meaning of the "Use the tab key to move focus between form
controls and links" checkbox in the Firefox settings, which was
introduced in bug 1628476 to override the system setting.
The intention, I think was that this checkbox being off resulted in
"follow the system" behavior, but that didn't quite happen due to a bug
in the preferences code (this[1] won't unset the pref, because of
this[2], which means we'll just return 0).
This patch changes it so that the checkbox instead always ignores the
system setting. There will no longer be a Firefox setting (neither in
the UI nor on about:config) that means "follow system setting".
This allows us to somewhat simplify the approach compared to the
previous patch in D196110, and keep the accessibility.tabfocus working
as the source of truth without a migration.
In the future, we can think of migrating accessibility.tabfocus to a
boolean pref, which would allow us to do the cleanups to the preferences
code that D196110 did.
[1]: https://searchfox.org/mozilla-central/rev/f1532761de0b60337e42c6c3f525288a523dabef/browser/components/preferences/main.js#2252
[2]: https://searchfox.org/mozilla-central/rev/f1532761de0b60337e42c6c3f525288a523dabef/toolkit/content/preferencesBindings.js#450,483
Differential Revision: https://phabricator.services.mozilla.com/D208602
