Just like it manages content, so that we stop chrome animations and such
in hidden or fully-occluded windows too. This already happened on macOS
for minimized windows via PauseCompositor, but this should be better and
more consistent.
Differential Revision: https://phabricator.services.mozilla.com/D151818
All its members are optional, so we can just use it as a plain struct
rather than Maybe<> all around, which simplifies the code and prevents
silly bugs like bug 1779592.
Mostly automatic via:
rg -l 'SVGImageContext' . | xargs sed -i 's/Maybe<SVGImageContext>/SVGImageContext/g'
With trivial build fixes.
Not intended to change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D151846
On some Android devices (predominantly Huawei devices running Android
9 or below) we are seeing large numbers of crashes due to the
compositor being unable to create an EGL surface to render in to. From
local testing, this appears to be due to the Surface we are being
provided from the SurfaceView being in an "abandoned"
state. Presumably this is due to an operating system bug - the Surface
is valid at the time of the surfaceChanged() callback, but becomes
abandoned moments later despite surfaceDestroyed() not being called.
We are able to detect when the Surface is in such a state from C++
code by calling ANativeWindow_getWidth(), as that will return a
negative value to indicate an error.
This patch uses this method to check whether the Surface is in such a
state prior to resuming the compositor. If so, rather than immediately
resuming the compositor it instead toggles the SurfaceView's
visibility. This tricks the SurfaceView in to providing a new (and
hopefully valid) Surface, which will in turn resume the compositor via
the surfaceChanged callback.
Differential Revision: https://phabricator.services.mozilla.com/D151479
Since callers want just an effective color to compute whether it's dark,
we simplify the API a bit too.
This makes sure we find the dark background in plain text documents.
Differential Revision: https://phabricator.services.mozilla.com/D151018
1. `requireInteraction` already existed, but it doesn't do anything.
This patch makes it mean `scenario="reminder"` in the Windows
Toast notification schema: see
https://docs.microsoft.com/en-us/uwp/schemas/tiles/toastschema/element-toast.
2. `actions` is intended to eventually support the Chrome-only
extension to the Web Notifications API: see
https://developer.mozilla.org/en-US/docs/Web/API/Notification/actions.
3. We run into an `xpconnect` limit on the number of supported
parameters. Rather than bump the limit, which has global
consequence, I added a second `init*` method. The existing
abstraction is horrible, but I can't rework it within my
timelines. Should we choose to invest, we might migrate to WebIDL
so that we can sensibly use options objects.
Differential Revision: https://phabricator.services.mozilla.com/D150667
This also provides an entry point for Windows-specific styling of
alerts, should specific consumers want one: e.g.,
`nsIWindowsAlertsService.showWindowsAlert(...)` allowing to configure
the toast template, for example.
Differential Revision: https://phabricator.services.mozilla.com/D151187
When the session storage prefs are enabled, GeckoSession updateSessionState will provide the bundle of information, including zoom, scroll, and form data, to the delegate. Currently works for Fission and on Fenix.
Differential Revision: https://phabricator.services.mozilla.com/D148215
`vaapitest()` is meant to be a sanity check. If it failed there's
likely something very broken about the driver and we log gfx
warnings accordingly, allowing to debug the problem.
Ensure to force-disable VAAPI in this case but still allow users
to enable the feature in blocklisted cases.
While on it add some additional fixes for issues encoutered while
testing:
- `InitVAAPIConfig()` was not run on X11-only builds, wrongly
setting `sLayersSupportsHardwareVideoDecoding` to `true` there
on allowlisted drivers. Thus replace `MOZ_WAYLAND` with
`MOZ_WIDGET_GTK`, ensuring the "Wayland support missing" warning
is shown in `about:support`.
- `UserForceEnable` must be run before `ForceDisable`, otherwise an
assert is triggered on debug builds. Reorder this.
- `GetFeatureStatus` was run twice for
`FEATURE_HARDWARE_VIDEO_DECODING`, once in `InitAcceleration()` in the
common code path, the again in `InitVAAPIConfig()`. Untangle the common
code path to only run `InitVAAPIConfig()`.
- Use the chance to turn `media.hardware-video-decoding.enabled` into a
static pref so it matches `media.hardware-video-decoding.force-enabled`
Differential Revision: https://phabricator.services.mozilla.com/D150959
`vaapitest()` is meant to be a sanity check. If it failed there's
likely something very broken about the driver and we log gfx
warnings accordingly, allowing to debug the problem.
Ensure to force-disable VAAPI in this case but still allow users
to enable the feature in blocklisted cases.
While on it add some additional fixes for issues encoutered while
testing:
- `InitVAAPIConfig()` was not run on X11-only builds, wrongly
setting `sLayersSupportsHardwareVideoDecoding` to `true` there
on allowlisted drivers. Thus replace `MOZ_WAYLAND` with
`MOZ_WIDGET_GTK`, ensuring the "Wayland support missing" warning
is shown in `about:support`.
- `UserForceEnable` must be run before `ForceDisable`, otherwise an
assert is triggered on debug builds. Reorder this.
- `GetFeatureStatus` was run twice for
`FEATURE_HARDWARE_VIDEO_DECODING`, once in `InitAcceleration()` in the
common code path, the again in `InitVAAPIConfig()`. Untangle the common
code path to only run `InitVAAPIConfig()`.
- Use the chance to turn `media.hardware-video-decoding.enabled` into a
static pref so it matches `media.hardware-video-decoding.force-enabled`
Differential Revision: https://phabricator.services.mozilla.com/D150959
1. `requireInteraction` already existed, but it doesn't do anything.
This patch makes it mean `scenario="reminder"` in the Windows
Toast notification schema: see
https://docs.microsoft.com/en-us/uwp/schemas/tiles/toastschema/element-toast.
2. `actions` is intended to eventually support the Chrome-only
extension to the Web Notifications API: see
https://developer.mozilla.org/en-US/docs/Web/API/Notification/actions.
3. We run into an `xpconnect` limit on the number of supported
parameters. Rather than bump the limit, which has global
consequence, I added a second `init*` method. The existing
abstraction is horrible, but I can't rework it within my
timelines. Should we choose to invest, we might migrate to WebIDL
so that we can sensibly use options objects.
Differential Revision: https://phabricator.services.mozilla.com/D150667
This also provides an entry point for Windows-specific styling of
alerts, should specific consumers want one: e.g.,
`nsIWindowsAlertsService.showWindowsAlert(...)` allowing to configure
the toast template, for example.
Differential Revision: https://phabricator.services.mozilla.com/D151187
This is the only thing from the regressing patch that could potentially
cause this macOS leak, realistically. I don't think the leak is
super-worrisome, likely we just shut down the browser before the image
load finishes.
Differential Revision: https://phabricator.services.mozilla.com/D151368
One possible cause of the failures to create an EGLSurface we are
seeing in bug 1772839 is that the Surface's underlying BufferQueue has
already been abandoned. In such circumstances,
ANativeWindow_getWidth/Height will return a negative value. If this
occurs, ensure we annotate crash reports via gfxCriticalNote. This
will allow us to determine whether the crashes we are seeing are
indeed due to an abandoned BufferQueue, or some other reason.
Differential Revision: https://phabricator.services.mozilla.com/D151360
We'll probably want to do something more accurate in the future with a
custom clang static analysis pass which validates that XPIDL interfaces
have the expected vtable and struct layout, however doing so would be
more involved than the string matching done in this patch.
In addition to checking for extra virtual methods, we'll likely also
want to check for data members on interfaces, and reject them unless the
class is marked as `[builtinclass]` in addition to some other attribute
which we'll need to add to prevent them from being implemented in Rust
(as c++ data members will not be reflected by the rust macro).
There were 2 instances of a comment which contained the word 'virtual'
within a CDATA block. These comments were moved out of the CDATA block
to avoid triggering the error.
Differential Revision: https://phabricator.services.mozilla.com/D151068
`browser.privacySegmentation.enabled` is going to be set when users opt into Felt Privacy. When I originally wrote some of this code I naively used it to pref things on, on the assumption that there would never be a situation where it would be `true` before 106 (when we remove the pref-off for this work).
However, we want to run an experiment with pinning private browsing to the taskbar ahead of 106. To avoid any possibility of accidentally opting users into Felt Privacy without their consent, let's use a distinct pref for turning these features off for now. This pref will disappear in the 106 cycle, as none of this code needs to be behind one at that point - so I don't _think_ this needs to go in `firefox.js`.
Differential Revision: https://phabricator.services.mozilla.com/D151065
Several widget contracts use different implementations in the parent and
content processes. Since the static registration system builds its hashtable
at compile time rather than runtime, it doesn't support different contract IDs
per process. It could make the decision at lookup time, but given how rarely
it's needed, I don't think it would be worth the complexity.
This patch updates the widget components that need different implementations
in the parent and content process to register separate contracts for each
implementation, and a third stub contract which forwards to the appropriate
implementation depending on which process it's used in. The implementation
entries restrict their usage to the process they are meant to be used in.
Differential Revision: https://phabricator.services.mozilla.com/D149436
nsIGfxInfo::FEATURE_HARDWARE_VIDEO_DECODING is used on all platforms so let's use it on Linux too and don't add new feature for Linux only.
Differential Revision: https://phabricator.services.mozilla.com/D149765
Reuse decoder device also to release on intel GPU on Windows, since it is also necessary for zero copy hardware decoded video.
Reuse decoder device handling is also updated as aligned to FEATURE_HW_DECODED_VIDEO_ZERO_COPY.
Differential Revision: https://phabricator.services.mozilla.com/D150448
This basically pref-gates some of the accent-color changes that landed before
the soft-freeze to match current release behavior, at least for now.
In the future we might want to reconsider turning these on, but at the very
least we should figure out a good story for the grey-ish accent colors, see the
comments in the pref definitions.
The only tricky bit is the use-theme-accent pref handling. I made it specific
to the non-native-theme again so that AccentColor and NNT kept behaving
consistently, but AccentColor in the browser chrome used the real accent color.
Differential Revision: https://phabricator.services.mozilla.com/D150339