NullPrincipal::Create() (will null OA) may cause an OriginAttributes bypass.
We change Create() so OriginAttributes is no longer optional, and rename
Create() with no arguments to make it more explicit about what the caller is doing.
MozReview-Commit-ID: 7DQGlgh1tgJ
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
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
These conditions are rare and do indicate a problem which breaks accessibility.
However, we aren't getting any closer to diagnosing these as a result of these crashes, so they cause user pain without any gain to us.
MozReview-Commit-ID: D9U4et3Bg7d
These conditions are rare and do indicate a problem which breaks accessibility.
However, we aren't getting any closer to diagnosing these as a result of these crashes, so they cause user pain without any gain to us.
MozReview-Commit-ID: D9U4et3Bg7d
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
Modifiers of shortcut keys may be same as modifier of content access keys.
When focus is in the main process, such eKeyPress event is sent to remote
content first. Then, and if it's not handled in the remote content,
eAccessKeyNotFound is dispatched into the DOM tree in the main process.
However, nsXBLWindowKeyHandler doesn't handle it as eKeyPress event. So,
it causes that shortcut keys whose modifier conflicts with content access key
won't be handled.
This patch just makes nsXBLWindowKeyHandler treat eAccessKeyNotFound as
eKeyPress event even though other shortcut keys which are handled by JS
won't be executed. Perhaps, we should stop using eAccessKeyNotFound but
it's too risky change for now.
MozReview-Commit-ID: IJltg5gwBc5
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
This is necessary because sometimes the async tab switcher will instantiate when
there already exists some background tabs that are rendering via print preview. When
that happens, it's important for the state to be set correctly for them so that we
don't accidentally treat them as still loading, and wait (forever) for them to report
having finished loading.
MozReview-Commit-ID: 2dwo5WlXlgJ
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
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
This is necessary because sometimes the async tab switcher will instantiate when
there already exists some background tabs that are rendering via print preview. When
that happens, it's important for the state to be set correctly for them so that we
don't accidentally treat them as still loading, and wait (forever) for them to report
having finished loading.
MozReview-Commit-ID: 2dwo5WlXlgJ
