This change is a continuation of Part 1 (Bug 1570128), where the 2D content rendered by Firefox for Firefox Reality on Desktop is marshalled through VRHost so that it can be presented in a VR environment.
A new class, FxrOutputHandler, is created to manage creating a sharable texture, sharing it through VRShMem, and updating it when content updates. This class updates content with both WebRender and conventional rendering output.
This initial iteration of FxrOutputHandler does not have synchronization between reading and writing this shared texture across processes. A subsequent fix (Bug 1581881) is pending, which will reuse WebVR code to manage writing to and reading from a pool of textures.
This also presents issues with rendering protected media, so an additional class, FxrWindowManager, is created to manage all windows created for Firefox Reality on Desktop so that it can inform whether or not protected media can be presented.
The automated manual tests in vrhosttest.cpp now show the real shared texture handle rather than a fake value, which shows that marshaling succeeded.
Differential Revision: https://phabricator.services.mozilla.com/D46179
--HG--
extra : moz-landing-system : lando
I've hit this in one of my try runs and looks trivial to fix.
The already_AddRefed destructor asserts when leaked.
We should just not allow to let it go out of scope without moving the pointer.
Differential Revision: https://phabricator.services.mozilla.com/D46942
--HG--
extra : moz-landing-system : lando
The `const` qualifier on `mVersion` was preventing move and copy, which we
now need this class to support.
Depends on D43158
Differential Revision: https://phabricator.services.mozilla.com/D43159
--HG--
extra : moz-landing-system : lando
We compare two file ids to check the current process is launched from the same
executable. However, our telemetry showed a number of Win7 users failed to open
a file handle of the parent process with STATUS_OBJECT_PATH_NOT_FOUND even
though we opened a process handle and retrieved a module path of the parent
process successfully. We don't have data to explain how this happens or why
this happens only on Win7, Win10 10240, and 10586.
To mitigate this situation, this patch introduces a logic to compare NT path
strings. The benefit from doing this is 1) we don't have to open a file handle
of a parent process executable and 2) when we get an NT path, a network drive
or a symbolic link is already solved.
This new logic is much faster, but we still compare file ids on the first
attempt to minimize the impact. We fall back to the new logic only if we
detect the STATUS_OBJECT_PATH_NOT_FOUND failure.
Differential Revision: https://phabricator.services.mozilla.com/D45476
--HG--
extra : moz-landing-system : lando
Even if `element.focus` is called from chrome, we always open virtual keyboard.
But I would like to change this behaviour that virtual keyboard isn't opened
via `element.focus` that is chrome script.
Depends on D44104
Differential Revision: https://phabricator.services.mozilla.com/D44105
--HG--
extra : moz-landing-system : lando
The `const` qualifier on `mVersion` was preventing move and copy, which we
now need this class to support.
Differential Revision: https://phabricator.services.mozilla.com/D43159
--HG--
extra : moz-landing-system : lando
`IMEContentObserver` sends selection change notification only when it receives
a DOM `Selection` change notification received. However, selection range in
plaintext offset may be changed when changing previous content of caret is
changed. In this case, currently we notify IME of only text change and
that causes IME keep caching selection offsets in previous content. This
causes IME queries character rect out of bounds. Therefore, even if
`IMEContentObserver` hasn't received DOM `Selection` change notification,
it should recompute selection range and if it's changed, it should notify
IME of selection change too.
Differential Revision: https://phabricator.services.mozilla.com/D46251
--HG--
extra : moz-landing-system : lando
The `const` qualifier on `mVersion` was preventing move and copy, which we
now need this class to support.
Differential Revision: https://phabricator.services.mozilla.com/D43159
--HG--
extra : moz-landing-system : lando
The `const` qualifier on `mVersion` was preventing move and copy, which we
now need this class to support.
Differential Revision: https://phabricator.services.mozilla.com/D43159
--HG--
extra : moz-landing-system : lando
Also causes removing a pref to take effect immediately, and prevents
losing all color pref overrides when the theme changes.
Differential Revision: https://phabricator.services.mozilla.com/D44416
--HG--
extra : moz-landing-system : lando
Adds nsIOSPermissionRequest::MaybeRequestScreenCapturePermission() to allow front-end code to trigger a screen-recording permission request dialog.
Depends on D46093
Differential Revision: https://phabricator.services.mozilla.com/D46094
--HG--
extra : moz-landing-system : lando
Adds nsIOSPermissionRequest::GetScreenCapturePermissionState() to allow front-end code to check if Firefox has already been granted permission to record the screen.
Differential Revision: https://phabricator.services.mozilla.com/D46093
--HG--
extra : moz-landing-system : lando
Adds a ServiceWorkerDelegate to GeckoRuntime that allows GeckoView applications
to handle ServiceWorkerClient.openWindow() requests.
Differential Revision: https://phabricator.services.mozilla.com/D45572
--HG--
extra : moz-landing-system : lando
This is regression by bug 1530649.
After landing bug 1530649, we try to scan end point of replacement text. But
in this bug's situation, afterRun becomes same as current ws run by landing
bug 1530649. To get white space type of next of replacement end, we have to
scan around end point again.
Differential Revision: https://phabricator.services.mozilla.com/D45947
--HG--
extra : moz-landing-system : lando
- Don't store whole buffer update information at mWholeWindowBufferDamage but use damage region instead.
- Check and remove overlapped images when they are stored at image cache.
- Remove CanDrawToWaylandBufferDirectly() as it's not very useful.
This commit depends on Bug 1580152 which needs to land first.
Differential Revision: https://phabricator.services.mozilla.com/D46140
--HG--
extra : moz-landing-system : lando
- Recently we're missing some drawings as we disabled flushing cached images in frame callback. Let's enable it again and make sure we don't flush the drawings between Lock()/Commit() compositor calls which is controlled by mBufferCommitAllowed.
- When we draw directly to wl_buffer, flush all cached drawings we have or clear them if there's fullscreen update. It prevents potential rendering of cached images over unrelevant buffer content.
- Flush cached images when wl_buffer is detached by wayland compositor. It allows to paint delayed drawings and ensures they won't stay in the queue infinitely.
- Use mBufferPendingCommit to indicate that the WaylandBuffer contains updates from gecko which has not been submitted to wayland compositor yet. Allows delated commit handlers (frame callback, delayed commit and when wl_buffer is detached) to send WaylandBuffer content to wayland compositor.
- Record time of last finished commit to mLastCommitTime and throws warning when wayland compositor does not release wl_buffer in 200ms.
- Use wl_display_sync() to synchronize wl_display events. Wait for events from wl_display until all pending events are processed before we start drawing at WindowSurfaceWayland::Lock(). There may wl_buffer release event waiting which releases wl_buffer for rendering.
- Don't use XMost()/YMost() to get drawing area size.
- Remove mDisplayThreadMessageLoop as it's no longer used.
Differential Revision: https://phabricator.services.mozilla.com/D45661
--HG--
extra : moz-landing-system : lando
The menuitem custom element inserts nodes when rendered. These nodes are
not related to the structure of the menu, but were causing nsMenuItemX
to mark the menu as needing a rebuild. The rebuild would remove all items
from the menu which caused the removal of the special menu items "Start
Dictation" and "Emoji and Symbols" that are automatically added by MacOS.
Differential Revision: https://phabricator.services.mozilla.com/D45420
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
The parent process usually starts a native drag session during the processing
of a Gecko mouse move event while the mouse is down. Usually, these Gecko mouse
move events are processed synchronously during -[ChildView mouseDragged:]. But
in some cases, the Gecko mouse move event can be a synthetic mouse move event
that was generated in response to a reflow. Those get processed during refresh
driver ticks, which run at a time that's completely unrelated to when
mouseDragged is invoked.
So the widget should just assume that drags can be started at any time between
mouseDown and mouseUp.
Differential Revision: https://phabricator.services.mozilla.com/D36151
--HG--
extra : moz-landing-system : lando