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
This never actually worked, because nothing ever listened to the notification
sent in XPCJSContext (kill-content-script-sandbox). We're also removing the
"Temporarily disable extension" button in the slow addon notification, which
was the primary caller of this - however, that's in a separate patch.
Differential Revision: https://phabricator.services.mozilla.com/D110583
Fairly straightforward - this removes the button from the slow add-on script
notification, as well as the functions that only it utilizes.
Differential Revision: https://phabricator.services.mozilla.com/D110582
This patch modifies the current CookieJarSettings::Create() function.
It removes the current function and adds two variants. One takes the
nsIPrincipal as input and another takes the enum value. The new
functions will test if the input is for the private browsing window to
create the corresponding cookieJarSettings.
Differential Revision: https://phabricator.services.mozilla.com/D109045
