Luminance goes from 0 to 255, so using 127 makes sense, and allows all
disabled titlebar colors that I found in various GTK themes to still be
considered dark enough (for those, 110 was too low).
Differential Revision: https://phabricator.services.mozilla.com/D114876
HangData is the only member left in the union and SLOW_SCRIPT is the only member left in the enum.
This patch also migrates the one remaining (invalid) use of PLUGIN_HANG in testing to work as a SLOW_SCRIPT instead.
Differential Revision: https://phabricator.services.mozilla.com/D113885
This will allow detecting the system theme, which allows fixing some of
the blocked bugs.
Note that when using the system theme we will still match light or dark
appropriately, so this shouldn't change behavior just yet.
Differential Revision: https://phabricator.services.mozilla.com/D113516
Stop supporting toolbar_field_separator in themes. We have no more
vertical separators in toolbar fields, and it could hide functional horizontal
separators in the urlbar panel, because it was misused there.
Introduce an autocomplete_popup_separator experimental color instead and use
a color-mix of currentColor to better adapt to LWT theme colors.
Differential Revision: https://phabricator.services.mozilla.com/D112616
This adds a new @media query -moz-toolbar-prefers-color-scheme which works like
prefers-color-scheme but is set based on the browser theme rather than the OS
theme. The background colour of the toolbar is used to determine the theme
dark/light preference. This will be used for in-content common.css pages and
other UI elements that include that stylesheet in the browser-chrome through
shadow DOM.
The end result is that about: pages, infobars, and modals will now "match" the
browser theme (just light/dark mode, not LWT theming support).
Differential Revision: https://phabricator.services.mozilla.com/D111486
This adds a new @media query -moz-toolbar-prefers-color-scheme which works like
prefers-color-scheme but is set based on the browser theme rather than the OS
theme. The background colour of the toolbar is used to determine the theme
dark/light preference. This will be used for in-content common.css pages and
other UI elements that include that stylesheet in the browser-chrome through
shadow DOM.
The end result is that about: pages, infobars, and modals will now "match" the
browser theme (just light/dark mode, not LWT theming support).
Differential Revision: https://phabricator.services.mozilla.com/D111486
This adds a new @media query -moz-toolbar-prefers-color-scheme which works like
prefers-color-scheme but is set based on the browser theme rather than the OS
theme. The background colour of the toolbar is used to determine the theme
dark/light preference. This will be used for in-content common.css pages and
other UI elements that include that stylesheet in the browser-chrome through
shadow DOM.
The end result is that about: pages, infobars, and modals will now "match" the
browser theme (just light/dark mode, not LWT theming support).
Differential Revision: https://phabricator.services.mozilla.com/D111486
Only the label was changed in bug 1694229, causing issues with the existing access key (still used in <89 for "Stop it").
Changing both IDs to force retranslation.
Differential Revision: https://phabricator.services.mozilla.com/D111576
It turns out the shadow document doesn't need its own FTL imports, the parent can
include them instead. This moves the requirement back onto the caller to ensure
that any FTL files it needs are already imported when creating a notification-message.
Depends on D111189
Differential Revision: https://phabricator.services.mozilla.com/D111190
This builds on D111205 by factoring out some initialization into a new
`initPageActionsTest()` in head.js. I'll need to use it in
browser_PageActions_newWindow.js too (bug 1703389).
Pre-Proton, there are 4 page action context menu items:
* Add to Address Bar
* Remove from Address Bar
* Manage Extension
* Remove Extension
Regardless of Proton, there are two context menus, one for buttons in the urlbar
and one for items in the page action panel. They're actually the same menu of
course.
This test currently checks each menu item in both context menus for a
non-built-in action except for the Remove Extension menu item. In Proton, we
don't need to check Add or Remove, so I modified the test to skip them. I also
added a check for the Remove Extension menu item. The test now must actually
create an extension with a page action to test the context menu because in
Proton only actions with extension IDs get the context menu (bug 1700364). Since
the test is creating an extension anyway, testing the Remove Extension menu item
isn't too hard.
Depends on D111205
Differential Revision: https://phabricator.services.mozilla.com/D111222
Removes NPAPI plugin features from tests outside of dom/plugins. Some tests are updated to avoid NPAPI behavior and others are deleted if they no longer offer anthing useful.
Differential Revision: https://phabricator.services.mozilla.com/D107134
Removes NPAPI plugin features from tests outside of dom/plugins. Some tests are updated to avoid NPAPI behavior and others are deleted if they no longer offer anthing useful.
Differential Revision: https://phabricator.services.mozilla.com/D107134
Emilio Cobos Álvarez
Toshihito Kikuchi
David Parks
Valentin Gosu
Csoregi Natalia
Emma Malysz
Butkovits Atila
Mike Conley
Cosmin Sabou
Joel Maher
Marco Bonardo
Mark Striemer
Narcis Beleuzu
Noemi Erli
Harry Twyford
Markus Stange
Francesco Lodolo (:flod)
Luca Greco
Michael Kohler
Jan-Ivar Bruaroey
Drew Willcoxon
Kershaw Chang
Doug Thayer