To more properly support Linux having a different default at runtime.
Expose the resolved value in appinfo for convenience, and use it in the
front-end as needed.
Differential Revision: https://phabricator.services.mozilla.com/D129004
We always use alpha visual for WebRender, and appearance: none is
unnecessary (root element has no intrinsic appearance).
Differential Revision: https://phabricator.services.mozilla.com/D128682
Bug 1718629 did this for the maximize button. This patch does the same for minimize and close, which we are switching to for consistent tooltip styling.
Differential Revision: https://phabricator.services.mozilla.com/D125625
We did two optimizations in this patch
1. Since mResourceEntries and mUserEntries are presorted
arrays, we could just merge them by iterating them over without
performing a quick sort.
2. Don't perform quick sort if entry type is provided.
Differential Revision: https://phabricator.services.mozilla.com/D124797
Windows 11's Snap Layouts feature generates a window of layout options when the maximize window button is moused over. This requires the WM_NCHITTEST message to handle hit detection for the button. Since WM_NCHITTEST messages are very common, although we limit them to no more than every 50ms, we don't want to do a full hit test each time. Instead, we cache the maximize button rect in the widget when it is positioned during layout.
Differential Revision: https://phabricator.services.mozilla.com/D123982
`onsecuritypolicyviolation` attribute has been added to `GlobalEventHandlers` by https://github.com/whatwg/html/pull/2651
List of tests:
1. w3c/web-platform-tests/dom/idlharness.window.html
2. w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-all-global-events.html
3. w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-attributes-body-window.html
4. w3c/web-platform-tests/mathml/relations/html5-tree/math-global-event-handlers.tentative.html
This new spec addition is already implemented in Safari[0] recently and Chromium[1] will be working on it soon.
[0] https://bugs.webkit.org/show_bug.cgi?id=229381
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=1242893
Differential Revision: https://phabricator.services.mozilla.com/D123891
Add initial support for the color-scheme CSS property, allowing pages to
choose between light and dark system colors per-element, and such.
Things that are left to do so that this can be enabled by default:
* Dark system colors on Windows / Android / Standins.
* Dark Canvas/CanvasText/Link visited colors (which right now are set
via PreferenceSheet).
* Dark form controls in nsNativeBasicTheme.
* Processing the color-scheme meta tag to fill-in
Document::mColorSchemeBits.
But this seems like enough progress to be landable on its own.
Differential Revision: https://phabricator.services.mozilla.com/D120843
Specifically:
For "bullets", i.e. 'list-style-type:disc|circle|square|
disclosure-closed|disclosure-open', we use a built-in font
(-moz-bullet-font, which has glyphs for those symbols + space) to
retain mostly backwards compatible rendering for those. Authors may
override that with an explicit 'font-family' ::marker style though.
We also use this font for 'list-style-image' in case it would
fallback to one of the above when the image fails to load (so that
we get the same width space).
When the -moz-bullet-font is used we also set 'font-synthesis' to
avoid synthesizing italic/bold for this font. Authors may override
this with an explicit ::marker declaration.
We also set 'letter-spacing' and 'word-spacing' to the initial value
for bullets for web-compat reasons. Again, authors may override
this with an explicit ::marker declaration. (This breaks backwards-
compat slightly but makes us compatible with Chrome. We used to
ignore these for list-style-type:<string> too.)
Differential Revision: https://phabricator.services.mozilla.com/D111693
Specifically:
For "bullets", i.e. 'list-style-type:disc|circle|square|
disclosure-closed|disclosure-open', we use a built-in font
(-moz-bullet-font, which has glyphs for those symbols + space) to
retain mostly backwards compatible rendering for those. Authors may
override that with an explicit 'font-family' ::marker style though.
We also use this font for 'list-style-image' in case it would
fallback to one of the above when the image fails to load (so that
we get the same width space).
When the -moz-bullet-font is used we also set 'font-synthesis' to
avoid synthesizing italic/bold for this font. Authors may override
this with an explicit ::marker declaration.
We also set 'letter-spacing' and 'word-spacing' to the initial value
for bullets for web-compat reasons. Again, authors may override
this with an explicit ::marker declaration. (This breaks backwards-
compat slightly but makes us compatible with Chrome. We used to
ignore these for list-style-type:<string> too.)
Differential Revision: https://phabricator.services.mozilla.com/D111693
ATK, Windows and XPCOM expect aria attribute keys to be stripped of
their aria- prefix. We should still store the item using the aria_ atom
and then strip the prefix when converting the key to a string.
Differential Revision: https://phabricator.services.mozilla.com/D116786
This patch does change the extension-related special case in SVGContextPaint::IsAllowedForImageFromURI
to check the "internal:svgContextPropertiesAllowed" extension permission, and move the existing
criteria in the Extension class (which takes care of adding the internal permission when those
criteria as met).
This patch does not contain yet a new explicit test case for the new internal permission (which is
part of the patch build on top of this one and attached to the same bugzilla issue), but it does
pass the existing mochitest-chrome (test_chrome_ext_svg_context_fill.html).
Differential Revision: https://phabricator.services.mozilla.com/D115835
This involves changing moveToAnchor to be allowed while the popup is showing. This change allows the buttons within the tab to use the normal algorithm for determining the tooltip position. This also fixes bug 1695900 so that tooltips for items in bookmarks menus also appear offset as well. Only the main tab and bookmarks on the toolbar appear aligned with the button's bottom edge.
Differential Revision: https://phabricator.services.mozilla.com/D115558
This will allow it to be used from UA sheets (we need static atoms there
to share UA sheets with other processes).
Depends on D113114
Differential Revision: https://phabricator.services.mozilla.com/D113115
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
Removes NPAPI support from JS plugin actors, most of which was CTP-and-fallback overlay related, leaving them to only do GMP crash handling.
Differential Revision: https://phabricator.services.mozilla.com/D107157
Removes NPAPI support from JS plugin actors, most of which was CTP-and-fallback overlay related, leaving them to only do GMP crash handling.
Differential Revision: https://phabricator.services.mozilla.com/D107157
