This is fairly straightforward, other than the fact that the
nomenclature gets a bit awkward with the aForce parameter on
the ForcePaint methods. I'm not sure which direction to go with
this - "aForce" seems a fairly intuitive name for what we want,
and I'm kind of inclined to say the existing ForcePaint mechanic
should be renamed to something like PaintWithInterrupt, or
PaintWithPriority.
MozReview-Commit-ID: Bj9DROug1pC
--HG--
extra : rebase_source : a3d91fec940d83325d36bafb13fe892e9c9530e8
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
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
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
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
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
When sending keyboard events from TabParent to its remote process, TabParent
may give higher priority to them than composition events and selectionset event.
Therefore, the event order between keyboard events and composition events (and
selection set event) may be broken. Keyboard events which should cause
inputting some characters are ignored if keyboard events are fired before
compositionend event accidentally.
This patch gives same priority to composition events and selectionset event
as keyboard event for avoiding breaking the event order.
MozReview-Commit-ID: 53jubwuHVvw
--HG--
extra : rebase_source : ddba2cce5980a354a47ded68e69ef973c00dac4b
Currently, IMEStateManager::OnChangeFocusInternal() tries to sync the state
whether menu keyboard listener is installed between itself and active remote
process -- When menu keyboard listener is installed, it posts a message to
_only_ active remote process. When menu keyboard listener is uninstalled,
it posts a message to _only_ active remote process. So, it's not guaranteed
that active remote process at installing and uninstalling may be different.
If it's different, IMEStateManager in the old remote process believes that
menu keyboard listener is still installed. This is what the cause of IME
unavailable in a remote process.
Current approach must be wrong. IMEStateManager should manage menu keyboard
listener state only in the process which the listener is installed in. Then,
when menu keyboard listener is uninstalled, IMEStateManager needs to restore
the latest input context in the remote process without asking the remote
process.
Therefore, this patch does:
* stops IMEStateManager::OnChangeFocusInternal() posting message when menu
keyboard listener is installed and uninstalled.
* removes the message sender and receiver from PBrowser.
* cache the latest input context of active remote process in
IMEStateManager::SetInputContextForChildProcess().
* make IMEStateManager::SetInputContextForChildProcess() not set input context
when menu keyboard listener is installed in the process.
* tries to restore latest input context in the remote process in
IMEStateManager::OnChangeFocusInternal(). If there is no cached input
context, it does nothing and waits next SetInputContextForChildProcess() call.
* clears the cache when IMEStateManager::OnChangeFocusInternal() changes
active remote process to different one or nullptr.
So, this must improve performance at activating and inactivating memubar and
opening and closing popup menu in the main process.
MozReview-Commit-ID: EelKSPlaXdw
--HG--
extra : rebase_source : db7334b3c0d3ce87868450ee3179692027975bd6
Telemetry and some performance profiles show that Msg_NotifyIMEFocus can take
a few seconds to complete, and jank the browser. With bug 1217700, it removes
the necessity of sync Msg_NotifyIMEFocus, so in this patch we make this async
for performance improvement.
MozReview-Commit-ID: 15eUwMJ2Q7H
--HG--
extra : rebase_source : b463e6e881ca5ebec00d0f76e29ca103059b3ddd
Doug Thayer
Jan de Mooij
Kartikaya Gupta
Boris Zbarsky
Peter Van der Beken
Coroiu Cristina
Peter Bacalso
Hector Zhao
Emilio Cobos Álvarez
Sebastian Hengst
Jeff Muizelaar
Masayuki Nakano
Tooru Fujisawa
Nika Layzell
Mike Conley
Kevin Chen
Bill McCloskey
sotaro
Stone Shih
Bevis Tseng
Wes Kocher
Henry Chang