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
Adding additional UI elements and filling out state machine with actualy UI updates. Some functions are stubbed out while waiting on ML to have API up on central. These UI changes should have no change to current UI if pref is turned off.
Differential Revision: https://phabricator.services.mozilla.com/D237277
Adding additional UI elements and filling out state machine with actualy UI updates. Some functions are stubbed out while waiting on ML to have API up on central. These UI changes should have no change to current UI if pref is turned off.
Differential Revision: https://phabricator.services.mozilla.com/D237277
Adding additional UI elements and filling out state machine with actualy UI updates. Some functions are stubbed out while waiting on ML to have API up on central. These UI changes should have no change to current UI if pref is turned off.
Differential Revision: https://phabricator.services.mozilla.com/D237277
Adding additional UI elements and filling out state machine with actualy UI updates. Some functions are stubbed out while waiting on ML to have API up on central. These UI changes should have no change to current UI if pref is turned off.
Differential Revision: https://phabricator.services.mozilla.com/D237277
Adding additional UI elements and filling out state machine with actualy UI updates. Some functions are stubbed out while waiting on ML to have API up on central. These UI changes should have no change to current UI if pref is turned off.
Differential Revision: https://phabricator.services.mozilla.com/D237277
Landing in moz-central the utility SmartTabGrouping class that enables smart tab grouping of browser tabs.
This includes some cleanup in the toolkit/../ml /code, including adding more tests.
We are slimming test data tsv files by using 5 dimensional embeddings instead of 500 dim.
There is still some algorithm code in /tabbrowser/SmartTabGrouping because it is tied up with tabs. We could maybe move some to toolkit/../ml if required but it is a little tricky.
With this patch landed, some clustering access would be available in the console by typing: gBrowser.smartTabGrouping()
@ngrato will have a separate patch to enable the UI.
Differential Revision: https://phabricator.services.mozilla.com/D237112
We just need to make sure all the throbber animations share a start
time, and we can use an arbitrary time (i.e., zero) rather than going
through all the tabs.
Differential Revision: https://phabricator.services.mozilla.com/D235300
