Now that GfxInfo supports allowlisting, we can port our existing
configuration in gfxPlatform to using allowlist rules. This will
greatly increase maintainability and certainty that the expected
devices are getting WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D62325
--HG--
extra : moz-landing-system : lando
A mochitest for this change will be landed in bug 1614268 which needs
a work to make Element.focus() work in OOP iframes (bug 1556627).
Differential Revision: https://phabricator.services.mozilla.com/D62191
--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
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--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
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
Currently the blocklist can block groups of devices, called a
DeviceFamily. However this only allows us to check specific IDs and not
ranges of device IDs like we do currently for the WebRender allowlist.
This patch allows a device family to now specify start and end values
for device IDs we want to match in the blocklist rule.
Differential Revision: https://phabricator.services.mozilla.com/D62324
--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
The blocklist currently works by checking the current configuration
against a set of GfxDriverInfo rules. We stop searching as soon as we
find the first match, and return whatever status code that has.
This patch adds a second pass for features marked for allowing. The
current blocklisting rules will still apply as normal. However it will
then review the allowlist rules using the same logic. If we don't get
a match, then we block the feature otherwise we use the allow status
code given in the rule.
New status codes introduced as part of this patch are as follows:
DENIED - Did not match any rules on the allowlist.
ALLOW_ALWAYS - Same as STATUS_OK but passed the allowlist.
ALLOW_QUALIFIED - Same as ALLOW_ALWAYS but should be controlled by
our qualified preference for experimentation purposes.
Differential Revision: https://phabricator.services.mozilla.com/D62322
--HG--
extra : moz-landing-system : lando
This change adds new "remote backbuffer" logic when compositing without
HW acceleration on Windows (IE compositing through Cairo using the Win32
GDI)
A new piece of shared memory is created between the GPU process and the UI
process, and the GPU process sends requests to the UI process to first "borrow"
a properly-sized buffer to draw into, and then sends a "present" request to
tell the UI process to actually blit the buffer to the Win32 window.
This is needed for the GPU sandbox to work, since Windows rightly doesn't
allow the untrusted GPU process to directly draw the contents of a window
owned by the trusted UI process.
Differential Revision: https://phabricator.services.mozilla.com/D61370
--HG--
extra : moz-landing-system : lando
Currently the blocklist can block groups of devices, called a
DeviceFamily. However this only allows us to check specific IDs and not
ranges of device IDs like we do currently for the WebRender allowlist.
This patch allows a device family to now specify start and end values
for device IDs we want to match in the blocklist rule.
Differential Revision: https://phabricator.services.mozilla.com/D62324
--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
The blocklist currently works by checking the current configuration
against a set of GfxDriverInfo rules. We stop searching as soon as we
find the first match, and return whatever status code that has.
This patch adds a second pass for features marked for allowing. The
current blocklisting rules will still apply as normal. However it will
then review the allowlist rules using the same logic. If we don't get
a match, then we block the feature otherwise we use the allow status
code given in the rule.
New status codes introduced as part of this patch are as follows:
DENIED - Did not match any rules on the allowlist.
ALLOW_ALWAYS - Same as STATUS_OK but passed the allowlist.
ALLOW_QUALIFIED - Same as ALLOW_ALWAYS but should be controlled by
our qualified preference for experimentation purposes.
Differential Revision: https://phabricator.services.mozilla.com/D62322
--HG--
extra : moz-landing-system : lando
This change adds new "remote backbuffer" logic when compositing without
HW acceleration on Windows (IE compositing through Cairo using the Win32
GDI)
A new piece of shared memory is created between the GPU process and the UI
process, and the GPU process sends requests to the UI process to first "borrow"
a properly-sized buffer to draw into, and then sends a "present" request to
tell the UI process to actually blit the buffer to the Win32 window.
This is needed for the GPU sandbox to work, since Windows rightly doesn't
allow the untrusted GPU process to directly draw the contents of a window
owned by the trusted UI process.
Differential Revision: https://phabricator.services.mozilla.com/D61370
--HG--
extra : moz-landing-system : lando
- Include va_drmcommon.h file to build without libva headers
- Clean up WaylandDMABufSurface/WaylandDMABufSurfaceRGBA/WaylandDMABufSurfaceNV12 classes
Differential Revision: https://phabricator.services.mozilla.com/D62415
--HG--
extra : moz-landing-system : lando
WaylandDMABufSurfaceNV12 holds HW decoded video frames from VA-API in NV12 format and it's implemented
as specialization of WaylandDMABufSurface base class.
Differential Revision: https://phabricator.services.mozilla.com/D62002
--HG--
extra : moz-landing-system : lando
We need WaylandDMABufSurface to hold both RGBA and YUV surfaces co create WaylandDMABufSurface as a base
class and derive WaylandDMABufSurfaceRGBA from it.
Differential Revision: https://phabricator.services.mozilla.com/D62001
--HG--
extra : moz-landing-system : lando
By falling back to the generic code like nsNativeThemeGTK does.
We may want to be more nuanced in other platforms? I don't know.
This is very noticeable on Riot and other apps that override the scrollbar width
/ scrollbar colors.
Differential Revision: https://phabricator.services.mozilla.com/D62634
--HG--
extra : moz-landing-system : lando
This issue is race condition of Gecko and Android/Java text change.
When VKB doesn't use `InputConnection.sendKeyEvent` for keyboard input, it use `android.text.Editable`. So keypress event is often emulated by text change of `Editable`. When dispatching keypress, if Gecko's text and Java's text is synchronized via `icSyncShadowText`, caret/cursor position is mismatched. So we shouldn't sync Java text (`Editable`) with Gecko's text.
So I would like to block for synchronizing text change during keypress is dispatched.
Differential Revision: https://phabricator.services.mozilla.com/D62013
--HG--
extra : moz-landing-system : lando
Now, we have `SpecialPowers` to use `DOMWindowUtils`. Therefore,
`test_bug1151186.html` can be a mochitest-plain and it's better since the
test checks behavior on web apps.
Depends on D62396
Differential Revision: https://phabricator.services.mozilla.com/D62397
--HG--
rename : widget/tests/test_bug1151186.html => editor/libeditor/tests/test_bug1151186.html
extra : moz-landing-system : lando
For testing the original symptom of bug 1151186, this test needs to set focus
to a `contenteditable` editor from `focus` event listener of the documen.
However, according to the oranges, `focus` event for the document is not fired
as expected only on Linux. The reason is, the document sometimes does not get
focus automatically. Therefore, this patch tries to listen `focus` event first
for keeping original path. But if the document is not activated automatically,
sets focus to its window when next macro task runs.
Differential Revision: https://phabricator.services.mozilla.com/D62396
--HG--
extra : moz-landing-system : lando
Window aspect ratio is known to work correctly on Gnome only so apply it only there.
Differential Revision: https://phabricator.services.mozilla.com/D62548
--HG--
extra : moz-landing-system : lando
Current implementation would fail to request a non-display wakelock on Windows when we ask for a background audio lock. The check for `audio-playing` with `locked-background` is incorrect. Therefore, adding new a variable to tell if we should request a non-display lock.
Differential Revision: https://phabricator.services.mozilla.com/D60201
--HG--
extra : moz-landing-system : lando
Bogdan Tara
Andrew Osmond
Emilio Cobos Álvarez
Masatoshi Kimura
Stephen A Pohl
Jonathan Watt
Cosmin Sabou
Hiroyuki Ikezoe
Haik Aftandilian
Mike Shal
Brindusan Cristian
Simon Giesecke
Chris Martin
Markus Stange
Csoregi Natalia
Martin Stransky
shindli
Marc Streckfuss
Coroiu Cristina
Makoto Kato
Masayuki Nakano
Kagami Sascha Rosylight
Xidorn Quan
alwu