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
Out of process support for Web extension creates another XUL widget for it.
We should calculate correct offset for Web Extension's remote widget.
MozReview-Commit-ID: AaALzLeKLsM
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive. This patch splits that macro into three new ones that are harder to
mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
The two happening at the same time can lead to the APZ autoscroll being
cancelled due to APZ receiving a main-thread scroll offset update.
To achieve this:
- The content process assumes APZ is handling the autoscroll until
told otherwise.
- If the parent process knows APZ won't handle an autoscroll, it
tells the content process via its response to the Autoscroll:Start
message. This covers all cases where APZ doesn't handle the
autoscroll, except the case where APZCTreeManager itself rejects
the autoscroll and it lives in the compositor process rather than
the parent process.
- If APZCTreeManager rejects an autoscroll and it lives in the
compositor process, it sends an 'autoscroll-rejected-by-apz' message
to the content process.
MozReview-Commit-ID: L62v4COai6W
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
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
Android now supports telling an IME that it shouldn't store user-entered content into it's dictionary/language model/etc. and we want to automatically enable this in private browsing.
As the code that handles input on Android doesn't have any notion of tabs (and therefore of the difference between normal and private tabs), the best way to get that info across is to retrieve it directly within the IMEStateManager from the corresponding document and store it in the inputContext, which is then passed to Java for Fennec to handle.
Implementing this within Gecko also has the benefit that this part of the code can be used by other platforms as well should they want to support similar features in the future.
MozReview-Commit-ID: DsxjC4Ma7DR
The messages are routed through nsITabParent, nsIWidget, and IAPZCTreeManager
(the latter possibly remoted via PAPZCTreeManager if out-of-process compositing
is used).
MozReview-Commit-ID: 1zXzLa1fqpG
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
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
The current code is wrong in several ways when transforms are applied, but
even if it were correct, it would give the wrong behavior. See comment in
patch for more details.
MozReview-Commit-ID: 3RaPuvENnWa
On-screen coordinates for points in remote frameloads are calculated relative
to the screen origin of the top-level window, while event coordinates are
calculated relative to the nearest widget. Since popups have their own widgets
separate from the top-level window, their native client offsets have no
particular relation to the origin of the top-level window, and we need to
manually calculate them relative to the origin of the top-level widget
instead.
MozReview-Commit-ID: EDyEyu37XuY
IME should receive notifications and requests only from proper process. E.g., IME shouldn't commit composition by a request which came from previous focused process.
This patch makes that IMEStateManager::NotifyIME() takes pointer to TabParent optionally. If the request or notification came from remote process, it should be non-nullptr. Then, this makes it ignore notifications and requests from unexpected process.
Note that this patch also touches some gfx headers because they use |ipc::| but compiler is confused at the ambiguousness between |mozilla::ipc::| and |mozilla::dom::ipc::|.
Finally, this patch changes the NS_ASSERTION in IMEHandler::OnDestroyWindow() to MOZ_ASSERT because the orange caused by the NS_ASSERTION was not realized since there was already an intermittent orange bug caused by different NS_ASSERTION.
MozReview-Commit-ID: 9CgKXQRJWmN
Currently, it's not been managed yet that whether an event is posted to at least one remote process. So, for managing the state, BaseEventFlags should have a new bool flag and WidgetEvent and BaseEventFlags should have helper methods for it.
Additionally, this fixes a bug of nsGUIEventIPC.h. In a lot of ParamTraits, static_cast<Foo> is used for using base class's ParamTraits. However, it causes creating temporary instance with copy constructor. Therefore, WidgetEvent::MarkAsPostedToRemoteProcess() call in ParamTraits<mozilla::WidgetEvent>::Write() didn't work as expected.
MozReview-Commit-ID: DdafsbVfrya
Currently, we have 2 bool flags (and optional 2 bool flags with related purpose) for managing propagation state between parent process and remote process. However, it's really complicated. Actually, setting these flags and referring the flags is usually follow explanation.
So, for making simpler, WidgetEvent and BaseEventFlags should have some utility methods for making them as self documented code.
This patch moves WidgetKeyboardEvent::mIsReserved to BaseEventFlags::mIsReservedByChrome. That allows us to manage the cross process event propagation state in same place.
MozReview-Commit-ID: IXEDQJ4GpAZ
