Same as the previous patch, the content iterator won't return non-`nsIContent`
node. Therefore, `HTMLEditor::HandleDeleteNonCollapsedSelection()` can treat
it with array of `nsIContent`.
Differential Revision: https://phabricator.services.mozilla.com/D61972
--HG--
extra : moz-landing-system : lando
The existing code just clipped to a rect. We need to do the same clipping that the non-remote code path does which also handles border radius.
The existing code is the from initial implementation of nsDisplayRemote in https://hg.mozilla.org/mozilla-central/rev/85d06279c8358a8e1c883aa670a20212b1039a90 so I suspect that clipping to the inner view bounds instead of the frame content box is not an important difference.
Differential Revision: https://phabricator.services.mozilla.com/D62180
--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
The content iterators always return `nsIContent` even though the result of
`GetCurrentNode()` is `nsINode*`. Therefore, we can make
`HTMLEditor::RemoveEmptyNodesIn()` use array of `nsIContent` instead of
array of `nsINode`.
Differential Revision: https://phabricator.services.mozilla.com/D61971
--HG--
extra : moz-landing-system : lando
Provides denylisted attributes to copy over in the fusing of chunked portions of the taskgraph. Without
denylisting these we have changes on these related kinds in json, due simply to ordering of total tasks.
Differential Revision: https://phabricator.services.mozilla.com/D62637
--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
- Update WaylandDMABUFTextureClientOGL to work with WaylandDMABufSurfaceRGBA which is used for GL/WebRender compositor
with dmabuf texture backend.
- Update WaylandDMABUFTextureHostOGL to work with both RGBA and NV12 surface formats.
- Use GLTextureSource instead of EGLImageTextureSource as we need to store more than one texture there with NV12
and pass the textures there by CreateTextureSourceForPlane().
- Implement NV12 related function by WaylandDMABUFTextureHostOGL (color space, color range, sub-textures num).
- Add NV12 implementation to PushResourceUpdates()/PushDisplayItems() for WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D62004
--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
We need to export more planes in SurfaceDescriptorDMABuf and also YUV color space.
Differential Revision: https://phabricator.services.mozilla.com/D62000
--HG--
extra : moz-landing-system : lando
There are two variation of the tests.
1) The image element gets visible by scrolling the iframe's scrollport.
2) The image element gets visible by scrolling the parent scroll container of the iframe
Depends on D61438
Differential Revision: https://phabricator.services.mozilla.com/D61439
--HG--
extra : moz-landing-system : lando
Though with this initial implementation, we do create an IntersectionObserver
only for the root document in each processes, once we found issues on this
model, we can create an IntersectionObserver in each _document_.
Depends on D61437
Differential Revision: https://phabricator.services.mozilla.com/D61438
--HG--
extra : moz-landing-system : lando
So that it can accept a callback function implemented in C++ for lazy-loading.
Depends on D61435
Differential Revision: https://phabricator.services.mozilla.com/D61436
--HG--
extra : moz-landing-system : lando
For HTML documents the onclose event is not dispatched to the root <html>
element.
Differential Revision: https://phabricator.services.mozilla.com/D62605
--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