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
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
The reported error happens because `.parentNode` can be a document,
which doesn't implement the Element interface. Using `.parentElement`
solves this issue.
And while I'm fixing this: move the logic behind the menu ID check, so
that the logic is not unnecessarily run for non-pageAction contextmenus.
Differential Revision: https://phabricator.services.mozilla.com/D116138
This is a bit peculiar. When we show the bookmarks toolbar, we create its children. When it then
gets hidden, they do not get removed. When we then re-enable the bookmarks toolbar, we call
`rebuild` on the next tick (because of the `await` in `init` in PlacesToolbarHelper), which
synchronously removes all the children of the toolbar, and then rebuilds the places node. It
does that async because it avoids doing synchronous layout flushes.
This breaks in the test - and the closer you put the "show the bookmarks toolbar" code to
the code that tries to open the context menu, the more reliably it breaks, because we try
to show the context menu right after we synchronously remove everything, and before we've
(asynchronously) put content back.
To avoid the raciness here, we wait for the custom event in the places toolbar to indicate
we're done building it.
Differential Revision: https://phabricator.services.mozilla.com/D116118
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
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
This doesn't seem a recent regression, the underlying issue is that we don't account for
the Extensions content scripts (and user scripts) as other principals that may be able
to intercept a drop event and then try to access the dataTransfer.files property before
the webpage does.
As the big inline comment inside DataTransferItemList::Files does explain, keeping a copy
of the FileList when accessed from a webpage principal is necessary for spec compliance,
while we don't cache it when it is being accessed by system principal code.
(see https://searchfox.org/mozilla-central/rev/6cbe34b441f7c7c29cd1e5f0e19c7000142f1423/dom/events/DataTransferItemList.cpp#200-242)
The changes in this patch are preventing us from caching the file list also when accessed
by expanded principals (which are never going to be used for any web page, but they are used
by both Extensions content scripts and Extensions user scripts), along with adding a new.
regression test to prevent it from regressing without being noticed.
Without this patch, when an extension content script or user script does intercept the
drop event and access the dataTransfer.files property, we cache the FileList created
for the ExpandedPrincipal associated to the Extension script and after that if the page
try to access it we do return null because the webpage principal doesn't subsume the
expanded principal (which is also why the issue isn't triggered if the webpage does
access it first). In debug build we crash because we hit the assertion in
DataTransferItemList::Files right before the earlier nullptr return we hit on release.
Differential Revision: https://phabricator.services.mozilla.com/D113555
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 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
