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
Currently, access key is handled in EventStateManager::PreHandleEvent() with eKeyPress event, i.e., before dispatching it into the DOM tree, if the access key is registered in EventStateManager. So, the main process does not check if the preceding eKeyDown event is consumed in focused remote process.
When preceding eKeyDown event is consumed in the main process, eKeyPress event won't be dispatched by widget. However, if remote process has focus, it's impossible widget to stop dispatching eKeyPress event because preceding eKeyDown event hasn't been handled in the focused remote process yet. Therefore, main process needs to post eKeyPress event to check if preceding eKeyDown event was consumed. When eKeyPress event is marked as "waiting reply from remote process", TabChild sends it back to the main process only when preceding eKeyDown event wasn't consumed. So, only when eKeyPress event is back to the main process, main process should handle accesskey with it.
This patch makes EventStateManager::PreHandleEvent() check if a remote target has focus before handling accesskey. If a remote process has accesskey and there is an accesskey matching with eKeyPress event, it marks the event as "waiting reply from remote content" and stop propagation in the process.
Finally, when eKeyPress event is sent back to TabParent, TabParent::RecvReplyKeyEvent() calls EventStateManager::HandleAccessKey() before dispatching the reply event into the DOM tree.
MozReview-Commit-ID: KsOkakaIVzb
--HG--
extra : rebase_source : 7e0c6966a1bde085e34d45bca4b0166b9fc2f3f1
EventStateManager checks if every keypress event's modifiers match with access key modifiers which are in prefs. Moving related methods of this to WidgetKeyboardEvent makes EventStateManager simpler and we can hide the NS_MODIFIER_* constants (they may make developers confused between Modifiers of WidgetInputEvent) into WidgetEventImpl.cpp.
MozReview-Commit-ID: 23NUQ51lJ1M
--HG--
extra : rebase_source : 341f3764ef62575577572d8b349159e2d5512b26