We don't need so many wrappers and so on. Similarly we don't need
.menu-right, we can use ::after to draw the arrow.
This makes reasoning about menus a lot easier.
Differential Revision: https://phabricator.services.mozilla.com/D245000
This patch changes the backing prefs by relying on the tristate offered
by browser.display.document_color_use instead of
browser.display.use_system_colors. This simplifies the color
decision tree, and offers a simplified UI.
The tristate preference offered to the user is as follows:
1. "Use platform's contrast settings" (document_color_use=0)
2. "Off" - never use HCM, regardless of platform setting (document_color_use=1)
3. "On" - always use HCM, regardless of platform setting (document_color_use=2)
Option 3 also reveals a colors UI for the user to choose the palette the
browser HCM will use (bg/text/link/visited).
There are three color palettes to choose from in light of the preference
above they are:
1. WIDGET_COLORS: The OS's configured colors used by its theme.
2. HARDCODED_COLORS: Colors deemed as standard and are hard coded into
Firefox (eg. white on black text, blue and purple links).
3. PREFERENCE_COLORS: Colors that are stored in preferences and are
configurable from the colors UI (eg. browser.visited_color and
browser.display.background_color)
The decision over which palette to use is as follows:
* If we are styling browser UI -> WIDGET_COLORS
* else, if resist fingerprinting is enabled -> HARDCODED_COLORS
* else, if document_color_use==0 AND OS HCM is on -> WIDGET_COLORS
* else, if document_color_use==2 -> PREFERENCE_COLORS
* else -> HARDCODED_COLORS
Differential Revision: https://phabricator.services.mozilla.com/D211115
This patch changes the backing prefs by relying on the tristate offered
by browser.display.document_color_use instead of
browser.display.use_system_colors. This simplifies the color
decision tree, and offers a simplified UI.
The tristate preference offered to the user is as follows:
1. "Use platform's contrast settings" (document_color_use=0)
2. "Off" - never use HCM, regardless of platform setting (document_color_use=1)
3. "On" - always use HCM, regardless of platform setting (document_color_use=2)
Option 3 also reveals a colors UI for the user to choose the palette the
browser HCM will use (bg/text/link/visited).
There are three color palettes to choose from in light of the preference
above they are:
1. WIDGET_COLORS: The OS's configured colors used by its theme.
2. HARDCODED_COLORS: Colors deemed as standard and are hard coded into
Firefox (eg. white on black text, blue and purple links).
3. PREFERENCE_COLORS: Colors that are stored in preferences and are
configurable from the colors UI (eg. browser.visited_color and
browser.display.background_color)
The decision over which palette to use is as follows:
* If we are styling browser UI -> WIDGET_COLORS
* else, if resist fingerprinting is enabled -> HARDCODED_COLORS
* else, if document_color_use==0 AND OS HCM is on -> WIDGET_COLORS
* else, if document_color_use==2 -> PREFERENCE_COLORS
* else -> HARDCODED_COLORS
Differential Revision: https://phabricator.services.mozilla.com/D211115
There's a few problems in the code gathering text data for nodes.
First it should not recurse into queries (included folder shortcuts) as it's
easy to create infinite recursion with them. The first level is excluded though,
as otherwise it would not be possible to copy contents of left pane roots.
Second it should requery folder shortcut contents in excludeItems results,
as otherwise it's not possible to copy contents of a root as text.
There's no longer the risk of dragging around root folders as this code is only
used for text flavors today, drag&drop uses serializeNode instead.
Differential Revision: https://phabricator.services.mozilla.com/D215068
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
