The new struct is in LayersTypes.h, all the rest of the changes are just
replacing existing uint64_t instances with the new LayersId struct.
Note that there is one functional change, in
CompositorBridgeParent::DeallocPWebRenderBridgeParent, where we now
correctly convert the PipelineId to a LayersId before using it to index
into sIndirectLayerTrees, whereas before we were incorrectly just using
the mHandle part of the PipelineId.
MozReview-Commit-ID: GFHZSZiwMrP
--HG--
extra : rebase_source : d2b274f63aaee2ee9bba030297e0a37a19af0d6c
The change in browser_net_view-source-debugger.js is needed because we now use WebIDL callbacks for MessageListener, and they add async creation stack frames.
--HG--
extra : rebase_source : 0adb349b40a0c51bb3d8f4b9b7d98106a3929cbd
extra : source : a88d94ec010a12c1d829708aaf59a85609478477
Most of them just want GetRootFrame(), and there's no need to explicitly go
through the frame manager for that, we have a handy alias in the shell.
MozReview-Commit-ID: GriEqkasidY
The change in browser_net_view-source-debugger.js is needed because we now use WebIDL callbacks for MessageListener, and they add async creation stack frames.
--HG--
extra : rebase_source : d7c026d8a77634ef2566feba78168beb8a66a552
It would be convenient to get nsPresContext from nsIDocument.
MozReview-Commit-ID: Ei6V3UE8XGr
--HG--
extra : rebase_source : 8d2a917eb62cf341e4e1810451fd01c01dbc3bad
When ContentChild::RecvInitRendering is received, it tries to setup the
IPDL actors related to rendering. If the GPU process crashes before or
during this process, it will fail, and cause the content process to
crash as well. This is unnecessary because the UI process will either
restart the GPU process, or subsume its job into itself, and trigger
ContentChild::RecvReinitRendering. It is a similar case for failures in
ContentChild::RecvReinitRendering.
Since the GPU process crashing should be a recoverable scenario, we now
check if the remote IPDL actor is in the UI or the GPU process. If it is
in the UI process, it will fail/crash as it does today. If it is in the
GPU process, it will wait for the next
ContentChild::RecvReinitRendering.
For failures that are not IPDL related (e.g. failed to get some resource
like spawning a thread), we release assert specifically for those
failures. They are not recoverable.
nsIDOMWindowUtils::sendKeyEvent() is already replaced with nsITextInputProcessor
for making callers set any attributes of KeyboardEvent and guaranteeing
consistency behavior with keyboard events caused by native key events. E.g.,
whether keypress event should be dispatched or not is automatically decided.
nsIFrameLoader::sendCrossProcessKeyEvent() is similart to
nsIDOMWindowUtils::sendKeyEvent() but it dispatches keyboard events in
child process directly. Currently, nsITextInputProcessor doesn't have this
feature but nobody wants/uses this feature. So, for removing actual
implementation of nsIDOMWindowUtils::sendKeyEvent(), i.e.,
nsContentUtils::SendKeyEvent(), which is shared by both
nsDOMWindowUtils::SendKeyEvent() and nsFrameLoader::SendCrossProcessKeyEvent(),
we should remove this unused API too. (FYI: it's implemented for old Fennec,
by bug 553149.)
MozReview-Commit-ID: 9n0UVo8Me8k
--HG--
extra : rebase_source : e9b117f5b9afec76e63d57ab8cd86dafb5873789
Calling GetPresShell() might create a content viewer, which might cause
script to run. This is bad if there's a ForcePaint message queued up,
because it could mean running the force painting code while we're still
in the midst of making a tab hidden, which would put us in an inconsistent
state.
MozReview-Commit-ID: 3rw2wGllGdk
--HG--
extra : rebase_source : 1c4b1ad28467fc6960eaa7cb744e47dd191b30f5
extra : source : 78073667ddc6e932408f49076b74c448a74bb710
This assumption also mirrors how non-remote browsers have their docShells active by default.
In order to do this, I also have to increase the initial epoch's for the TabParent and TabChild,
as if a RenderLayers has been called. Originally, since the epochs initted at 0, and the epochs
stored by the [Layer|WebRender]TransactionParent were also initted at 0, we'd hit this branch:
https://searchfox.org/mozilla-central/rev/c633ffa4c4611f202ca11270dcddb7b29edddff8/gfx/layers/ipc/LayerTransactionParent.cpp#703
and then we'd never alert the TabParent about the layer upload.
MozReview-Commit-ID: 6PP1eCnisYK
--HG--
extra : rebase_source : 4ca9f692635e3a3a1ec8e626d0db24f2e512ec9a
extra : source : b9b2895b11a32f3da0f4c8fe364bf3bdfc7defb6
Originally, setting the active state on the DocShell for remote browsers also did the
work of making the TabChild render its layers and upload them to the compositor.
This patch adds a new renderLayers method to nsITabParent which allows more fine-grained
control - we can now, for example, cause layers to be rendered and uploaded without
activating the DocShell.
Note that if one activates or deactivates the DocShell, we'll still do the work of
attempting to render / clear the layers if it hasn't already been done.
MozReview-Commit-ID: KkLaMDTzfHi
--HG--
extra : rebase_source : 6c53729ae4b07c67d9e3de99c12e1165a85ffaac
extra : source : 261be8ec05542a9e50c0ca03a59a8a44997269b7
Calling GetPresShell() might create a content viewer, which might cause
script to run. This is bad if there's a ForcePaint message queued up,
because it could mean running the force painting code while we're still
in the midst of making a tab hidden, which would put us in an inconsistent
state.
MozReview-Commit-ID: 3rw2wGllGdk
--HG--
extra : rebase_source : 152716d81391ea4d890927a0dadff912c53a28e2
This assumption also mirrors how non-remote browsers have their docShells active by default.
In order to do this, I also have to increase the initial epoch's for the TabParent and TabChild,
as if a RenderLayers has been called. Originally, since the epochs initted at 0, and the epochs
stored by the [Layer|WebRender]TransactionParent were also initted at 0, we'd hit this branch:
https://searchfox.org/mozilla-central/rev/c633ffa4c4611f202ca11270dcddb7b29edddff8/gfx/layers/ipc/LayerTransactionParent.cpp#703
and then we'd never alert the TabParent about the layer upload.
MozReview-Commit-ID: 6PP1eCnisYK
--HG--
extra : rebase_source : da736415d6b60208fa54bc25fe449cc261e856d8
Originally, setting the active state on the DocShell for remote browsers also did the
work of making the TabChild render its layers and upload them to the compositor.
This patch adds a new renderLayers method to nsITabParent which allows more fine-grained
control - we can now, for example, cause layers to be rendered and uploaded without
activating the DocShell.
Note that if one activates or deactivates the DocShell, we'll still do the work of
attempting to render / clear the layers if it hasn't already been done.
MozReview-Commit-ID: KkLaMDTzfHi
--HG--
extra : rebase_source : 2d00dc71c584a41650696a412b6249aee3a505fe
The property in question is the offset from the content process to the
chrome process, but it gets called various things for historical
reasons. Let's be consistent and just call it the chrome offset
everywhere.
Also, in some places this was needlessly getting turned into a
nsIntPoint via ToUnknownPoint(), only to be turned back into a
LayoutDeviceIntPoint at all the use sites. So this patch also updates
some function signatures to avoid the needless conversion.
No functional changes.
MozReview-Commit-ID: AuhEUfa64Uj
--HG--
extra : rebase_source : 20e1895fefd944f98307a8437f977252ee2c3185
