This patch adds a blank page about:third-party along with a skeleton XPCOM
object AboutThirdParty which has a method to invoke a background task in C++.
Differential Revision: https://phabricator.services.mozilla.com/D109303
Share the concept of a panel content with all other menupopups / panels.
This avoids importing global.css in the shadow tree, and renames the
arrowcontent part to just "content", since we want to introduce a
"content" part for other panels.
This shouldn't change behavior but makes bug 1708136 a matter of
tweaking a couple CSS rules and fixing up test failures.
Differential Revision: https://phabricator.services.mozilla.com/D113990
This patch adds a blank page about:third-party along with a skeleton XPCOM
object AboutThirdParty which has a method to invoke a background task in C++.
Differential Revision: https://phabricator.services.mozilla.com/D109303
Using autofocus="true" or programmatically calling .focus() when there is no pre-existing focused
element causes the :focus-visible to match.
This patch avoids using autofocus="true" on some of our about: pages, and uses
Element.focus({ preventFocusRing: true }) to avoid that when these pages and dialog
first load. Note that this doesn't prevent the focus ring from _ever_ appear, it just
stops it from appearing on first load.
Differential Revision: https://phabricator.services.mozilla.com/D115062
This resolves a failure in browser/base/content/test/pageActions-proton/browser_PageActions_bookmark.js. That test checks the tooltiptext on the bookmark button hbox. Before part 1 of this patch, the hbox always had one of the generic tooltiptexts "Bookmark Current Tab"/"Edit This Bookmark". This tooltiptext was set in updateBookmarkPageMenuItem. Then, in __updateStar, we set the tooltiptext on the <image> contained in the hbox to be "Bookmark this page ([shortcut])"/"Edit this bookmark ([shortcut])". Since the <image> filled the entire hbox, the tooltiptext on the hbox underneath was never seen. Since Part 1 of this patch moved the semantic meaning of the page action buttons from the <image> to the hbox, the tooltiptext containing the shortcut was also moved to the hbox. However, updateBookmarkPageMenuItem was overriding the shortcut tooltiptext with the generic text and thus browser_PageActions_bookmark.js was failing intermittently. The timing of when the tooltiptext was overridden was variable.
This patch stops setting the generic tooltiptext on the hbox altogether. I'm splitting this out into its own patch since I think it needs its own review. With Part 1 applied, when actually using the browser, the hbox had the tooltiptext with the shortcut. I'm not totally clear on why that was working despite updateBookmarkPageMenuItem overriding it, so I'd like to make sure this change is okay.
Depends on D114131
Differential Revision: https://phabricator.services.mozilla.com/D115485
To resolve this bug, we need page action icons and semantic page action nodes to be separate. That way, we can apply filters to the icons without also filtering the nodes' outlines. This means the semantic meaning of the page action button must move up a level, to the enclosing hbox. This means reverting bug 1482025, so I'd like a11y review on this patch.
Differential Revision: https://phabricator.services.mozilla.com/D114131
@babel/transform-flow-strip-types and eslint-plugin-flowtype are no longer required as devtools removed the uses of them in bug 1690742.
Differential Revision: https://phabricator.services.mozilla.com/D115402
To resolve this bug, we need page action icons and semantic page action nodes to be separate. That way, we can apply filters to the icons without also filtering the nodes' outlines. This means the semantic meaning of the page action button must move up a level, to the enclosing hbox. This means reverting bug 1482025, so I'd like a11y review on this patch.
Differential Revision: https://phabricator.services.mozilla.com/D114131
We don't support storing blob recordings in the surface cache at this
time so we should never look at it. It is possible that one may request
a blob recording, and have a previous rasterization available in the
cache because it was used in canvas or as a repeating background image.
We want to explicitly avoid the cache in that case.
Differential Revision: https://phabricator.services.mozilla.com/D115136
Using autofocus="true" or programmatically calling .focus() when there is no pre-existing focused
element causes the :focus-visible to match.
This patch avoids using autofocus="true" on some of our about: pages, and uses
Element.focus({ preventFocusRing: true }) to avoid that when these pages and dialog
first load. Note that this doesn't prevent the focus ring from _ever_ appear, it just
stops it from appearing on first load.
Differential Revision: https://phabricator.services.mozilla.com/D115062
We don't support storing blob recordings in the surface cache at this
time so we should never look at it. It is possible that one may request
a blob recording, and have a previous rasterization available in the
cache because it was used in canvas or as a repeating background image.
We want to explicitly avoid the cache in that case.
Differential Revision: https://phabricator.services.mozilla.com/D115136
Broadly, this patch does 2 things:
- it mirrors the logic bug 1702258 introduced for <select> styling for <option> styling
- it enforces that if the website specifies custom foreground colours for options,
we use the website-specified colour for the option background, too (even if it
matches the UA/select style).
I also added automated testing for 3 cases:
1. the default dark mode situation (where we expect dark mode styles),
2. the case from the bug where the website specifies `#fff` for the background
of the select and the background of the options, but specifies a custom
foreground colour for the option (but not the select).
3. a very similar case where the website only specifies the background on the
select, and only the foreground on the option.
Differential Revision: https://phabricator.services.mozilla.com/D114382
Now that I finally wrote a test, I also noticed that we were trying to write the
checkbox permission value when the dialog gets aborted (ie removed because the
page disappears due to another page loading or the tab/window being closed),
which then threw an exception because the event target is the window rather than
the dialog element, and dialog.querySelector in maybeSetAllowTabSwitchPermission
fails.
Differential Revision: https://phabricator.services.mozilla.com/D114023
Similar to bug 1707182 (browser_autoSubmitRequest.js) tests using the
crashreporter on Apple Silicon fail to execute properly.
Differential Revision: https://phabricator.services.mozilla.com/D113928
