This also changes CompositorBridgeChild to create the CanvasChild lazily.
Depends on D44154
Differential Revision: https://phabricator.services.mozilla.com/D44873
--HG--
extra : moz-landing-system : lando
In places where profiler_is_active() was used around a profiler_add_marker() (or
similar) call, replace it with profiler_can_accept_markers().
Differential Revision: https://phabricator.services.mozilla.com/D44435
--HG--
extra : moz-landing-system : lando
Payloads will serialize themselves into a `BlocksRingBuffer` entry when first
captured.
Later they will be deserialized, to stream JSON for the output profile.
Differential Revision: https://phabricator.services.mozilla.com/D43428
--HG--
extra : moz-landing-system : lando
Previously after RecvResumeAndResize() we would set a flag on the root
WebRenderBridgeParent, which in turn sets a flag on the next display list it
receives that it should be treated as a first paint. Then when that display list
is finally composited, we call UiCompositorControllerParent::NotifyFirstPaint(),
which in turn tells GeckoView to uncover the widget.
After switching tabs in GeckoView browsers, however, the root
WebRenderBridgeParent does not always receive a new display list, so the widget
would not be uncovered. Instead of waiting for the next received display list to
be composited, we simply want to uncover the widget on the next composite. To
achieve this we instead set the forced-first-paint flag on the root
CompositorBridgeParent then we call NotifyFirstPaint() during
CompositorBridgeParent::NotifyPipelineRendered().
Differential Revision: https://phabricator.services.mozilla.com/D46157
--HG--
extra : moz-landing-system : lando
In places where profiler_is_active() was used around a profiler_add_marker() (or
similar) call, replace it with profiler_can_accept_markers().
Differential Revision: https://phabricator.services.mozilla.com/D44435
--HG--
extra : moz-landing-system : lando
Payloads will serialize themselves into a `BlocksRingBuffer` entry when first
captured.
Later they will be deserialized, to stream JSON for the output profile.
Differential Revision: https://phabricator.services.mozilla.com/D43428
--HG--
extra : moz-landing-system : lando
Note that the areas are clipped out by all ancestor scroll ports and
their coordinate systems are the screen coordinate. So that we can tell
arbitrary elements in out-of-process iframes are scrolled out or not with
this area and the transform matrix of the iframe on screen coodinate.
Differential Revision: https://phabricator.services.mozilla.com/D44420
--HG--
extra : moz-landing-system : lando
The rect will be used for calculating the result of the composition of the
remote display item on the compositor.
Differential Revision: https://phabricator.services.mozilla.com/D44419
--HG--
extra : moz-landing-system : lando
This also makes sure the SourceSurfaceCanvasRecording clean-up is done on the
main thread where required.
Differential Revision: https://phabricator.services.mozilla.com/D43077
--HG--
extra : moz-landing-system : lando
Null checks have been added for the recorder in CanvasChild to prevent crashes
during shutdown.
This also removes mCanSend in CanvasParent and uses CanSend() instead.
Differential Revision: https://phabricator.services.mozilla.com/D43076
--HG--
extra : moz-landing-system : lando
Most of our keyboard shortcut handling is handled by nsXBLWindowKeyHandler along
with nsXBLPrototypeHandler. With the impending removal of XBL this needs to
change.
This patch moves nsXBLWindowKeyHandler to dom/events/GlobalKeyListener and copies
nsXBLPrototypeHandler to dom/events/KeyEventHandler. Windows, text elements and
XUL <keyset> are changed to use the new copies and anything unnecessary for
those is stripped out.
XBL handler elements still remain using the existing nsXBLPrototypeHandler path.
Some of the code is ripped out there to make it compile. There is probably a
lot more that can be removed but since the whole of XBL is likely gone soon I'm
not sure it is worth cleaning that up much.
Differential Revision: https://phabricator.services.mozilla.com/D42336
--HG--
rename : dom/xbl/nsXBLWindowKeyHandler.cpp => dom/events/GlobalKeyListener.cpp
rename : dom/xbl/nsXBLWindowKeyHandler.h => dom/events/GlobalKeyListener.h
rename : dom/xbl/nsXBLPrototypeHandler.cpp => dom/events/KeyEventHandler.cpp
rename : dom/xbl/nsXBLPrototypeHandler.h => dom/events/KeyEventHandler.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForBrowserCommon.h => dom/events/ShortcutKeyDefinitionsForBrowserCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForEditorCommon.h => dom/events/ShortcutKeyDefinitionsForEditorCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForInputCommon.h => dom/events/ShortcutKeyDefinitionsForInputCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForInputCommon.h => dom/events/ShortcutKeyDefinitionsForTextAreaCommon.h
rename : dom/xbl/builtin/ShortcutKeys.cpp => dom/events/ShortcutKeys.cpp
rename : dom/xbl/builtin/ShortcutKeys.h => dom/events/ShortcutKeys.h
rename : dom/xbl/builtin/android/ShortcutKeyDefinitions.cpp => dom/events/android/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/android/moz.build
rename : dom/xbl/builtin/emacs/ShortcutKeyDefinitions.cpp => dom/events/emacs/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/emacs/moz.build
rename : dom/xbl/builtin/mac/ShortcutKeyDefinitions.cpp => dom/events/mac/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/mac/moz.build
rename : dom/xbl/builtin/unix/ShortcutKeyDefinitions.cpp => dom/events/unix/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/unix/moz.build
rename : dom/xbl/builtin/win/ShortcutKeyDefinitions.cpp => dom/events/win/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/win/moz.build
extra : moz-landing-system : lando
This change introduces plumbing for communicating with the GPU process through
VRShMem while bootstrapping Firefox for creating a window with Firefox Reality.
Test impact shows a fabricated value returned for the texture handle in VRShMem.
Differential Revision: https://phabricator.services.mozilla.com/D41383
--HG--
extra : moz-landing-system : lando
Gather stats for most calls to `profiler_add_marker()`, including the time to
allocate payloads if any.
Differential Revision: https://phabricator.services.mozilla.com/D43420
--HG--
extra : moz-landing-system : lando
All calls to `profiler_add_marker()` (outside of the profilers code) are
now replaced by either:
- `PROFILER_ADD_MARKER(name, categoryPair)`
- `PROFILER_ADD_MARKER_WITH_PAYLOAD(name, categoryPair, TypeOfMarkerPayload,
(payload, ..., arguments))`
This makes all calls consistent, and they won't need to prefix the category pair
with `JS::ProfilingCategoryPair::`.
Also it will make it easier to add (and later remove) internal-profiling
instrumentation (bug 1576550), and to replace heap-allocated payloads with
stack-allocated ones (bug 1576555).
Differential Revision: https://phabricator.services.mozilla.com/D43588
--HG--
extra : moz-landing-system : lando
Now that there is only ever a single handle to the `CompositionRecorder`, it no
longer needs to be ref-counted. And since the `WebRenderCompositionRecorder` is
owned exclusively by the `RenderThread`, it no longer needs a mutex. All the
code that resulted from having handles to the `WebRenderCompositionRecorder` on
two different threads is now no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D39791
--HG--
extra : moz-landing-system : lando
Since we are not writing frames to disk from the `CompositorBridgeParent` in
the WebRender case, we do not actually need a handle to the
`(WebRender)CompositionRecorder` there. Instead, the `HostLayerManager` and
`RenderThread` can maintain exclusive handles to these objects. This will allow
us to use unique pointers for these objects and delete code in a follow up
patch.
Differential Revision: https://phabricator.services.mozilla.com/D39790
--HG--
extra : moz-landing-system : lando
On macOS, if we try to write the collected frames from the
`CompositorBridgeParent` we will not have an active GL context, resulting in a
crash. Writing the frames from the `RenderThread` solves this problem.
Differential Revision: https://phabricator.services.mozilla.com/D39789
--HG--
extra : moz-landing-system : lando
Instead of blindly attempting to write frames to disk, we now ensure that the
`CompositionRecorder` exists. In the case where we have not allocated one,
calling `windowUtils.setCompositionRecording(false)` will instead print an
error message to the browser console.
In addition, attempting to call `windowUtils.setCompositionRecording(true)`
while a `CompositionRecorder` exists will also result in an error message.
Differential Revision: https://phabricator.services.mozilla.com/D39584
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
--HG--
extra : moz-landing-system : lando
This is done my adding two new canvas RecordedEvents, which add and remove the
SourceSurfaceCanvasRecording as an alias to the SourceSurfaces that they wrap.
Differential Revision: https://phabricator.services.mozilla.com/D37089
--HG--
extra : moz-landing-system : lando
This also fixes the CanvasParent destruction on channel close and error,
which was broken due to IPDL changes between rebases.
Differential Revision: https://phabricator.services.mozilla.com/D37088
--HG--
extra : moz-landing-system : lando
Currently it's completely unclear at use sites that the getters for `once`
static prefs return the pref value from startup, rather than the current pref
value. (Bugs have been caused by this.) This commit improves things by changing
the getter name to make it clear that the pref value obtained is from startup.
This required changing things within libpref so it distinguishes between the
"base id" (`foo_bar`) and the "full id" (`foo_bar` or
`foo_bar_DoNotUseDirectly` or `foo_bar_AtStartup` or
`foo_bar_AtStartup_DoNotUseDirectly`; the name used depends on the `mirror` and
`do_not_use_directly` values in the YAML definition.) The "full id" is used in
most places, while the "base id" is used for the `GetPrefName_*` and
`GetPrefDefault_*` functions.
(This is a nice demonstration of the benefits of the YAML file, BTW. Making
this change with the old code would have involved adding an entry to every
single pref in StaticPrefList.h.)
The patch also rejigs the comment at the top of StaticPrefList.yaml, to clarify
some things.
Differential Revision: https://phabricator.services.mozilla.com/D38604
--HG--
extra : moz-landing-system : lando