The goal here is to ensure we can always rely on `AppShutdown::GetShutdownPhase` to be in sync with the "real" application status, mainly this was needed for xpcshell tests to not break if we add assertions on our shutdown state on some global singletons.
We keep the existing observer notification topics but force them (on the parent process) to be issued through the new `advanceShutdownPhase` function of the startup service using the `ShutdownPhase` enum. This way we can synchronize `AppShutdown`'s internal status accordingly.
Some further notes:
# The `MOZ_ASSERT(AppShutdown::IsNoOrLegalShutdownTopic(aTopic));` in `NotifyObservers` helped a lot to identify missing cases. I think we should keep it in order to stay safe.
# Introducing the `cenum IDLShutdownPhase` helps to keep the knowledge about the mapping from shutdown phases to observer topics exclusively inside AppShutdown.cpp. Still callers must know what they do in order to choose a proper phase, of course.
# However we must be aware that `AppShutdown` this way can be kept in sync with the shutdown notifications only in the parent process and that `GetCurrentShutdownPhase` might not give the correct result in child processes. We might want to file a follow up bug that adds some asserts to avoid improper use of `AppShutdown` functions in child processes (but I do not want to make this patch bigger as needed to solve the blocking dependency for bug 1697972).
# The socket process is one example of a child process that "overloads" shutdown topics. I was wondering if it is the right call to use the very same topic names here to request shutdown to the socket process or if it should have its own topics. Those topics triggered the assert and thus I had to disable it for child processes, for now.
# This goes together with the more general approach to define process type specific shutdown phases (and hence mappings to topics) as drafted very roughly in bug 1697745.
# This patch seemed to trigger a known intermittent more often, thus the change here in `ServiceWorkerManager`.
Differential Revision: https://phabricator.services.mozilla.com/D124350
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
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
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 is for a few reasons:
* The leak logging isn't as useful as other types of logging, as
nsTArray_base is frequently relocated without invoking a constructor,
such as when stored within another nsTArray. This means that
XPCOM_MEM_LOG_CLASSES cannot be used to identify specific leaks of
nsTArray objects.
* The nsTArray type is layout compatible with the ThinVec crate with the
correct flags, and ThinVec does not currently perform leak logging.
This means that if a large number of arrays are transferred between rust
and C++ code using ThinVec, for example within another ThinVec, they
will not be logged correctly and might appear as e.g. negative leaks.
* Leaks which have been found thanks to the leak logging added by this
type have often not been significant, and/or have needed to be
circumvented using some other mechanism. Most leaks found with this type
in them also include other types which will continue to be tracked.
Differential Revision: https://phabricator.services.mozilla.com/D115087
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
