There's no reason we can't just query LookAndFeel and we need to use
sSystemMetrics. In the past, LookAndFeel queries were not cached, but
this is no longer the case, so perf wise should be pretty equivalent.
Note that we don't need the NS_SUCCEEDED checks because the default
value from GetInt if the platform doesn't support it is 0 anyways.
Differential Revision: https://phabricator.services.mozilla.com/D110805
Implement an observer to wait for correct window events in order to restore tab
content. Non-SHIP code restores about:reader scroll position after receiving
"AboutReaderContentReady" event, so to achieve the same thing with session
history in parent enabled, we can wait for "AboutReader:Ready" event.
Differential Revision: https://phabricator.services.mozilla.com/D108712
The SpinEventLoopUntilOrShutdown is interrupted in the main process only at stage "xpcom-shutdown", which is too late. In a content process instead we interrupt it early enough, at "content-child-will-shutdown".
This patch removes the current observer logic in nsThreadManager in favor of a current shutdown phase state machinery in AppShutdown and renames SpinEventLoopUntilOrShutdown to SpinEventLoopUntilOrQuit. It also ensures that SpinEventLoopUntilOrQuit breaks early (at "quit-application" in the main process).
For a further possible cleanup around shutdown state in child and parent process please refer to bug 1697745.
We have no automated test for this edge case, but we have diagnostic telemetry that will tell us if it helps.
Differential Revision: https://phabricator.services.mozilla.com/D107619
Previously we were initializing IOUtils lazily when we received our first IO
request, but that could run into problems when
1. shutdown starts before submitting any IO requests, which would then fail to
add shutdown blockers for phases we have already passed; or
2. the first IO request comes from off-main-thread, which can not tell if the
shutdown blockers are added successfully.
Now we register an observer to initialize the event queue and add all startup
blockers in the `profile-after-change` phase. We can then be sure that IOUtils
will have its blockers added before `profile-before-change`.
Differential Revision: https://phabricator.services.mozilla.com/D105700
These services had their name added to components.conf:
* GfxInfo
* ThirdPartyUtil
* History
* HttpActivityDistributor
* UUIDGenerator
* ServiceWorkerManager
* PermissionManager
These services were added to componenets.conf under a different name:
* DirectoryService => Directory
* IOService => IO
* StringBundleService => StringBundle
* CacheStorageService => CacheStorage
* StreamTransportService => StreamTransport
* SocketTransportService => SocketTransport
These services weren't migrated to components.conf because only Rust
code uses them:
* RemoteAgent
* XULRuntime
* PrefService
These services weren't migrated to components.conf because they're unused:
* ToolkitChromeRegistry (used as ChromeRegistry)
* XULChromeRegistry (used as ChromeRegistry)
* Bits (completely unused)
These services were already available in components.conf but are still
used by rust code:
* URIFixup
These services weren't migrated because they will be handled in
subsequent patchsets:
* ObserverService
For the record, the following Services are being used by Rust code
and must remain until a Rust version of Components.h is written:
* RemoteAgent
* XULRuntime
* PrefService
* URIFixup
* ObserverService
* DirectoryService
* ThirdPartyUtil
Also the cocoa GfxInfo service was changed to use components.conf instead
of registering it at runtime, as all the other widgets were already doing
it this way.
Differential Revision: https://phabricator.services.mozilla.com/D105521
These changes make nsDisplayCompositorHitTestInfo inherit directly from nsDisplayItem, which should shrink it slightly. This also simplifies the logic: hit testing information is now available at nsDisplayItem level as opposed to nsPaintedDisplayItem.
Differential Revision: https://phabricator.services.mozilla.com/D103773
These changes make nsDisplayCompositorHitTestInfo inherit directly from nsDisplayItem, which should shrink it slightly. This also simplifies the logic: hit testing information is now available at nsDisplayItem level as opposed to nsPaintedDisplayItem.
Differential Revision: https://phabricator.services.mozilla.com/D103773
Note that there's still a little plugin related code in
widget/ and gfx/ etc after this. That can be removed
once we remove plugin support from dom/ etc.
The removal from layout/ should be pretty complete though.
Differential Revision: https://phabricator.services.mozilla.com/D102140
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Which allows to run CSS.supports in chrome/user-agent context. We should
probably add a couple more tweaks for stuff like quirks or what not (the
`ParsingMode` enum), but that seem lower priority.
I only added the one-value version of CSS.supports because it should be enough
and supporting the two value version required a bit of awkward code due to when
we parse the CSS property name right now.
Differential Revision: https://phabricator.services.mozilla.com/D92585
This allows it to be forward-declared (while a nested class cannot be),
such that headers files that use RectCallback by pointer or reference
do not need to include nsLayoutUtils.h.
This avoids including nsLayoutUtils.h in nsRange.h.
Differential Revision: https://phabricator.services.mozilla.com/D91685
Also: adjust include paths to be consistent for usages of various SVG headers,
and remove unused SVG includes (mostly for "utils" classes),
and drop stray "ns" from already-renamed SVG classes in various code comments.
Differential Revision: https://phabricator.services.mozilla.com/D83140
Dynamically toggle support for displaying image/webp and image/avif according
to the values of the image.webp.enabled and image.avif.enabled prefs.
Differential Revision: https://phabricator.services.mozilla.com/D76977
There are many limitations currently, but this prototype should successfully
render most basic AVIF images. Known limitations:
- No support for any derived image items (crop, rotate, etc.)
- No support for alpha planes
- No support for ICC profiles (bug 1634741)
- The primary image item must be an av01 (no grid support)
- HDR images aren't tone-mapped
Differential Revision: https://phabricator.services.mozilla.com/D68498