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 makes it trivial to choose the right BrowserParent to print a
browsing context, by removing the OuterWindowID / FrameLoader
indirections.
Differential Revision: https://phabricator.services.mozilla.com/D112412
1) Stop setting the image attribute for extension menu checkbox items. They
don't work with the new custom chekbox appearance CSS, and not shown anyway.
2) When gutter is visible, stop padding menu items with an icon outside of it,
and use the gutter as a place for said icons.
3) Adjust margin for menu items with icons to align the text with the rest of
the menu items when the gutter is visible.
Differential Revision: https://phabricator.services.mozilla.com/D112267
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 capability is used by browser_ext_menus_capture_secondary_click.js, which
checks that the mouse button is correctly propagated when clicking menu items.
Once bug 1704879 is fixed and activateItem supports specifying a mouse button,
we can revert this patch again.
Differential Revision: https://phabricator.services.mozilla.com/D111901
This is likely the low risky option:
- in this patch: identify the modal prompts triggered by extensions options page embedded in about:addons and use the openContenPrompt
for them
- in a separate follow up issue (to be files), once we are ready to rip off the content prompt code
(and the related about:config pref):
- stop using openContentPrompt
- remove the stack XUL element currently used in about:addons to host the content prompts
- adapt the test case to the new prompts (e.g. using PromptTestUtils to wait for the modal prompt),
Differential Revision: https://phabricator.services.mozilla.com/D110530
This is likely the low risky option:
- in this patch: identify the modal prompts triggered by extensions options page embedded in about:addons and use the openContenPrompt
for them
- in a separate follow up issue (to be files), once we are ready to rip off the content prompt code
(and the related about:config pref):
- stop using openContentPrompt
- remove the stack XUL element currently used in about:addons to host the content prompts
- adapt the test case to the new prompts (e.g. using PromptTestUtils to wait for the modal prompt),
Differential Revision: https://phabricator.services.mozilla.com/D110530
- implement the new "inspected-window" command
- move WebExtensionInspectedWindowFront implement to the command, making the front empty
- migrate tests to use the commands instead of front
- stop maintaining the current top level target in ExtensionParent.jsm, no longer have to use watchTargets
- stop creating a new descriptor on each new target
- instead only pull one new dedicated "commands" for WebExt (still in ExtensionParent.jsm)
- remove TabDescriptor isDevToolsExtensionContext as we no longer need anything special in the descriptor
- remove now unused methods on DevToolsShims (createWebExtensionInspectedWindowFront, createDescriptorForTabForWebExtension)
- remove the now unused TabDescriptorFactory.createDescriptorForTab's "forceCreationForWebextension" option, as CommandsFactory.forTab always instantiate a brand new commands
- migrate webext to use the command instead of front
Differential Revision: https://phabricator.services.mozilla.com/D108994
`swapBrowsersAndCloseOther` calls `SessionStore.setTabState`, but the
latter may trigger several tab events before the tab has fully been
restored. This results in duplicate tabs.onUpdated events and in
unexpected access to properties of the tab/browser (which in turn
triggers the reported bug).
Fix this specific case by ignoring events that happen while the tab is
amidst a restoration.
Differential Revision: https://phabricator.services.mozilla.com/D108259
Given the result span problem described in bug 1699211 and bug 1699607,
currently there's no way for quick suggest to accurately specify the last index
as its suggested index.
Differential Revision: https://phabricator.services.mozilla.com/D109571
This migrates WebNavigation.jsm to use messages from PExtensionsParent
generated by the native WebNavigationContent class, and removes the now-unused
WebNavigationContent.js frame script.
Differential Revision: https://phabricator.services.mozilla.com/D103217
This migrates WebNavigation.jsm to use messages from PExtensionsParent
generated by the native WebNavigationContent class, and removes the now-unused
WebNavigationContent.js frame script.
Differential Revision: https://phabricator.services.mozilla.com/D103217
The test basically was written for Fission, but unfortunately it fails
intermittently without Fission becasue, I assume, there was a pre-existing race
condition causing the failure without Fission, so we are going to skip the
test without Fission for now.
Differential Revision: https://phabricator.services.mozilla.com/D109250
This migrates WebNavigation.jsm to use messages from PExtensionsParent
generated by the native WebNavigationContent class, and removes the now-unused
WebNavigationContent.js frame script.
Differential Revision: https://phabricator.services.mozilla.com/D103217
This migrates WebNavigation.jsm to use messages from PExtensionsParent
generated by the native WebNavigationContent class, and removes the now-unused
WebNavigationContent.js frame script.
Differential Revision: https://phabricator.services.mozilla.com/D103217
- Add a question mark to the prompt title.
- Remove redundant promp message.
- Pass window to prompt to use new tab-modal format.
Differential Revision: https://phabricator.services.mozilla.com/D107539
Depends on D107099
With the previous patch, we are waiting for toolbox open before creating contexts.
This makes some tests a bit racy if they are only waiting for toolbox open. They should also wait for the context to be ready.
Firing an event from the devtools_page seems to work fine for this but don't hesitate to suggest a better approach.
Differential Revision: https://phabricator.services.mozilla.com/D107100
Depends on D107099
With the previous patch, we are waiting for toolbox open before creating contexts.
This makes some tests a bit racy if they are only waiting for toolbox open. They should also wait for the context to be ready.
Firing an event from the devtools_page seems to work fine for this but don't hesitate to suggest a better approach.
Differential Revision: https://phabricator.services.mozilla.com/D107100
Per conversations with Bas, we want the behavior for slow extensions to match
that of slow content scripts WRT requiring user input. The test change is less
than great, but I don't think we have the ability to simulate input in
mochitests without running JS in the content process? But correct me if I'm
wrong.
Differential Revision: https://phabricator.services.mozilla.com/D107521
The patch for bug 1498432 will include a unit test that uses
tabs.onUpdated with the "url" filter for "properties".
The updated test here verifies that the tabs.onUpdated event does not
include other properties in changeInfo when filtering by "status".
Differential Revision: https://phabricator.services.mozilla.com/D106733
The patch for bug 1498432 will include a unit test that uses
tabs.onUpdated with the "url" filter for "properties".
The updated test here verifies that the tabs.onUpdated event does not
include other properties in changeInfo when filtering by "status".
Differential Revision: https://phabricator.services.mozilla.com/D106733
While using -moz-os-version selectors in a shared CSS file isn't ideal, I think it's the best approach here. These selectors will hopefully be temporary, and will be removed when bug 1695280 is fixed. I considered a creating a ruleset like
```
@media (-moz-os-version: windows-win7),
(-moz-os-version: windows-win8) {
#navigator-toolbox:-moz-lwtheme {
background-color: unset;
}
:root:-moz-lwtheme {
background-color: var(--lwt-accent-color);
}
}
```
in browser/themes/windows/browser.css, but I think unsetting the background-color could become a headache if we need to make any other changes to the #navigator-toolbox background. We could also move these background rules to platform-specific stylesheets, but that way they're defined much later in the CSS despite being fairly foundational rules. It would also create more code to remove in bug 1695280.
Differential Revision: https://phabricator.services.mozilla.com/D106670
This patch removes the wait button on the slow script warning, on the suspicion
that it is confusing to the user since it's redundant with the close button. It
also changes the text of the notification to blame the hanging tab.
Differential Revision: https://phabricator.services.mozilla.com/D106015
tab.hasTabPermission indirectly triggers an access to
browser.currentURI, which for lazy tab browsers causes an incorrect
value to be cached. To avoid this, skip the call to hasTabPermission.
Differential Revision: https://phabricator.services.mozilla.com/D106622
