Change the GetScreenCapturePermissionState() heuristic to use the full window list instead of just on-screen windows to allow it it to work in full screen mode.
Differential Revision: https://phabricator.services.mozilla.com/D70931
--HG--
extra : moz-landing-system : lando
Also move MOZ_MUST_USE before function declarations' specifiers and return type. While clang and gcc's __attribute__((warn_unused_result)) can appear before, between, or after function specifiers and return types, the [[nodiscard]] attribute must precede the function specifiers.
Differential Revision: https://phabricator.services.mozilla.com/D68148
--HG--
extra : moz-landing-system : lando
The bugs is reproducible only with all Korean IMEs of Apple only on Catalina.
Until Apple fixes the bug, we should not allow the Korean IMEs to consume
mouse events. (I think that we should keep notifying all mouse events for
backward compatibility.)
Differential Revision: https://phabricator.services.mozilla.com/D67285
--HG--
extra : moz-landing-system : lando
`PlaybackState` and `MediaSessionPlaybackState` are actually quite similar, and we don't want to have to many states to confuse reader and do unnecessary tranform between two states. Therefore, replaceing `PlaybackState` with `MediaSessionPlaybackState`.
Differential Revision: https://phabricator.services.mozilla.com/D66342
--HG--
extra : moz-landing-system : lando
gfx::Color is currently misused in many places. The DrawTargets expect
the color space to be in device space, e.g. what we are actually going
to draw using. Everything sitting above generally deals with sRGB, as
specified in CSS. Sometimes we missed the conversion from sRGB to device
space when issuing draw calls, and similarly sometimes we converted the
color to device space twice.
This patch splits the type in two. sRGBColor and DeviceColor now
represent sRGB and device color spaces respectively. DrawTarget only
accepts DeviceColor, and one can get a DeviceColor from an sRGBColor via
the ToDeviceColor helper API. The reftests now pass with color
management enabled for everything (e.g. CSS) instead of just tagged
raster images.
There will be a follow up patch to enable color management everywhere by
default on all supported platforms.
Differential Revision: https://phabricator.services.mozilla.com/D64771
--HG--
extra : moz-landing-system : lando
This should be less confusing. This is not supported outside of chrome:// or
user-agent stylesheets so we can name this however we want.
Differential Revision: https://phabricator.services.mozilla.com/D65605
--HG--
extra : moz-landing-system : lando
This allows testing much more easily.
There are some edge cases with native theme changes and such (ThemeChanged and
co assume there's only one theme per process). But I don't think they matter
much for our use cases.
Differential Revision: https://phabricator.services.mozilla.com/D65162
--HG--
extra : moz-landing-system : lando
I don't think we want to keep the ugly widget hacks forever. Let me know if
you'd rather keep the property behind a pref but I don't think there's a point
in doing that.
Differential Revision: https://phabricator.services.mozilla.com/D62649
--HG--
extra : moz-landing-system : lando
I don't think we want to keep the ugly widget hacks forever. Let me know if
you'd rather keep the property behind a pref but I don't think there's a point
in doing that.
Differential Revision: https://phabricator.services.mozilla.com/D62649
--HG--
extra : moz-landing-system : lando
Update the heuristic-based screen recording permission check to be more
reliable but still imperfect.
Add pref "media.macos.screenrecording.oscheck.enabled" (true by default) to
allow bypassing the permission check as a workaround and for testing.
i.e., when the pref is set,
nsIOSPermissionRequest::getScreenCapturePermissionState() always returns
PERMISSION_STATE_AUTHORIZED on macOS.
Differential Revision: https://phabricator.services.mozilla.com/D61909
--HG--
extra : moz-landing-system : lando
We would like to get to a world where we compare/store enums instead of
strings, and this is a step towards.
Differential Revision: https://phabricator.services.mozilla.com/D62503
--HG--
extra : moz-landing-system : lando
As part of the WebRender rollout, we have been only allowing users
meeting particular platform, battery and screen size requirements (among
others) to get WebRender by default. This patch adds support for battery
and screen size filters in the blocklist rules to allow us to control
that more easily. It also adds kludgey support for checking for recent
Windows 10 build numbers for allowlist purposes; implementing this the
proper way would require an implementation like driver version checks,
which are much more complicated than most of the rules.
Differential Revision: https://phabricator.services.mozilla.com/D62323
--HG--
extra : moz-landing-system : lando
As part of the WebRender rollout, we have been only allowing users
meeting particular platform, battery and screen size requirements (among
others) to get WebRender by default. This patch adds support for battery
and screen size filters in the blocklist rules to allow us to control
that more easily. It also adds kludgey support for checking for recent
Windows 10 build numbers for allowlist purposes; implementing this the
proper way would require an implementation like driver version checks,
which are much more complicated than most of the rules.
Differential Revision: https://phabricator.services.mozilla.com/D62323
--HG--
extra : moz-landing-system : lando
This patch also exposes the desktop environment and window protocol on
the gfx blocklist, allowing us more control over feature deployment.
This will help with the slow rollout of WebRender to release channels.
Differential Revision: https://phabricator.services.mozilla.com/D56563
--HG--
extra : moz-landing-system : lando
This patch also exposes the desktop environment and window protocol on
the gfx blocklist, allowing us more control over feature deployment.
This will help with the slow rollout of WebRender to release channels.
Differential Revision: https://phabricator.services.mozilla.com/D56563
--HG--
extra : moz-landing-system : lando
The event source's playback state can represent if the media is currently playing. Therfore, whenever it changes, we should update the media center's playback state as well in order to show correct controller icon (eg. play and pause) on the touch bar.
Differential Revision: https://phabricator.services.mozilla.com/D60024
--HG--
extra : moz-landing-system : lando
Now both of GTK and MacOSX backends use the same machinery, LookAndFeelInt, for
prefers-reduced-motion. And we are going to use it on Android as well so it'd
make sense to move the code into there.
On Windows we can also use the same LookAndFeelInt machinery and probably
all we have to do is to call SendNotifyMessage with SPI_SETCLIENTAREAANIMATION
in SetPrefersReducedMotionOverrideForTest.
Differential Revision: https://phabricator.services.mozilla.com/D59022
--HG--
extra : moz-landing-system : lando
Now both of GTK and MacOSX backends use the same machinery, LookAndFeelInt, for
prefers-reduced-motion. And we are going to use it on Android as well so it'd
make sense to move the code into there.
On Windows we can also use the same LookAndFeelInt machinery and probably
all we have to do is to call SendNotifyMessage with SPI_SETCLIENTAREAANIMATION
in SetPrefersReducedMotionOverrideForTest.
Differential Revision: https://phabricator.services.mozilla.com/D59022
--HG--
extra : moz-landing-system : lando