Our implementation was setting a custom user agent on the document
before reloading it, and then resetting it as soon as the document
was loaded.
In Chrome, once the webextension sets the user agent, it persists
across reload and navigations, and is reset only when the toolbox
is closed.
This patch is adding similar behaviour to our implementation.
We also set the currentUserAgent flag on the browsing context from
the parent process instead of content. This is re-using the
targetConfigurationCommand, which also handle for us resetting the
user agent when the toolbox closes.
The existing test is expanded so it includes a remote iframe to ensure
the feature is supported on Fission. It also check the value of the user
agent through navigator.userAgent, and not only through the request header.
Differential Revision: https://phabricator.services.mozilla.com/D112980
Our implementation was setting a custom user agent on the document
before reloading it, and then resetting it as soon as the document
was loaded.
In Chrome, once the webextension sets the user agent, it persists
across reload and navigations, and is reset only when the toolbox
is closed.
This patch is adding similar behaviour to our implementation.
We also set the currentUserAgent flag on the browsing context from
the parent process instead of content. This is re-using the
targetConfigurationCommand, which also handle for us resetting the
user agent when the toolbox closes.
The existing test is expanded so it includes a remote iframe to ensure
the feature is supported on Fission. It also check the value of the user
agent through navigator.userAgent, and not only through the request header.
Differential Revision: https://phabricator.services.mozilla.com/D112980
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
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
`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
