When WebRender creation is failed, WebRender is disabled in gecko. There is a case that WebRenderBridgeParents exist when WebRender is disabled. To handle this, gecko needs to rebuild all CompositorSessions.
There is also a problem related to gfxVars::UseWebRender on compositor thread. If e10s is enabled, but no-gpu process(default on linux and mac), gfxVars::UseWebRender change is soon notified by compositor thread tasks. If WebRender creation failure happens at 2nd WebRender creation, several WebRenderBridgeParents for 1st WebRender could exist. IPC messages from WebRenderLayerManager are normally async, then there is a chance that the WebRenderBridgeParents receive the messages after the gfxVars::UseWebRender change. Further the gfxVars::UseWebRender change in content process could be delayed than WebRenderBridgeParents, then content process does not have a way to stop sending PWebRenderBridge IPC until the change of gfxVars::UseWebRender is received. WebRenderBridgeParent related tasks handle the message, but some tasks are done based on gfxVars::UseWebRender. At this time, gfxVars::UseWebRender returned false on compositor thread, then it cause unexpected result for WebRenderBridgeParent and WebRender. To addres this inconsistent situation, WebRenderBridgeParent related tasks on compositor thread stop to use gfxVars::UseWebRender.
To make the HeadlessCompositorWidget work under Windows as well as Linux, I had
to change the way that I hooked it into the existing CompositorWidget system.
Under GTK, the CompositorWidgetInitData and CompositorWidgetDelegate types
provided the information needed by the headless compositor widget already (the
widget client size). On Windows, however, the definitions of these types
differ, and the client size information is simply retrieved from the platform
APIs when needed.
After this patch, CompositorWidgetDelegate is renamed to
PlatformCompositorWidgetDelegate, and a new base class called
CompositorWidgetDelegate is added with "AsPlatformSpecificDelegate()" and
"AsHeadlessCompositorWidget()" methods. In non-headless mode, widgets use
AsPlatformSpecificDelegate() to access the Windows- and GTK-specific delegate
APIs. In headless mode, AsHeadlessCompositorWidget() is used to access the
singular CompositorWidget implementation for headless. Meanwhile, the
CompositorWidgetInitData IPDL type is made into a union which always contains a
headless-specific HeadlessCompositorWidgetInitData struct and under GTK and
Windows also contains an {X11,Win}CompositorWidgetInitData struct.
This also includes a small patch to ensure that the GPU process and
hardware-accelerated compositing are always disabled under headless mode. These
features weren't activated by default in the Linux environments I tested in, but
did end up activating (and then promptly crashing Firefox) when I tested on
Windows.
MozReview-Commit-ID: CocPoHBDV7H
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
nsIWidget::NotifyIME() should call only TextEventDispatcher::NotifyIME() if it's necessary. Then, TextEventDispatcher::NotifyIME() calls TextEventDispatcherListener::NotifyIME() if it's necessary. E.g., requests to IME are necessary only for TextInputProcessor or native IME handler because the composition is only owned by one of them. However, notifications are necessary for both of them since focused editor contents and its focus state are shared.
So, it doesn't need to call nsBaseWidget::NotifyIMEInternal() if all NotifyIMEInternal() implementations are moved to proper TextEventDispatcherListener::NotifyIME(). Currently, nsBaseWidget::NotifyIMEInternal() is implemented only by PuppetWidget. It sends notifications and requests to the parent process for native IME. Therefore, we can move NotifyIMEInternal() implementation to TextEventDispatcherListener::NotifyIME() which is implemented by PuppetWidget.
This patch moves PuppetWidget::NotifyIMEInternal() implementation to PuppetWidget::NotifyIME() of TextEventDispatcherListener class, not of nsIWidget and removes NotifyIMEInternal() completely.
With this change, handling order is changed. Old behavior is, TextEventDispatcher::NotifyIME() calls TextEventDispatcherListener::NotifyIME() before handling NOTIFY_IME_OF_FOCUS and then, nsBaseWidget::NotifyIME() sends the notification to the parent process. However, new behavior is, the notification is sent before TextEventDispatcher::NotifyIME() handles NOTIFY_IME_OF_FOCUS. Therefore, with new handling order, TextEventDispatcher can have IME notification requests after setting focus correctly. Additionally, TextEventDispatcher for PuppetWidget updates the notification requests at every event dispatch via TextEventDispatcher::BeginInputTransactionInternal() by the previous patch.
So, with those patches, IMEContentObserver can refer actual IME notification requests correctly even after we'll make focus notification to async message.
MozReview-Commit-ID: JwdQ68BjTXL
Ideally, we definitely want APZ in remote popup browsers for the sake of
responsiveness. However, there are currently some serious painting and
checkerboarding issues that make APZ popups unsuitable for release
populations.
Once these issues are addressed, we should enable the preference by default.
But given the relative lack of testing, and the issues we've seen so far, we
should keep the preference so that we can disable it with a hotfix if further
issues arise.
MozReview-Commit-ID: GOZRdsmLNZR
Currently, IMEStateManager always sets input context as set by current process even when it needs to adjust IME state when a tab parent for current focused IME process is removed. Then, input context for the widget is marked as for main process but the widget still have IME focus of a remote process.
For fixing this mismatch, IMEStateManager should set ORIGIN_CONTENT even when the tab parent is being destroyed.
MozReview-Commit-ID: C10YOAtkET4
When keyboard apz is disabled, we don't need to calculate focus targets and
we don't need to update focus state. It should be harmless even if it's done,
but I think it's good to not add something on this critical path that doesn't
do anything.
This commit also disable keyboard map generation in this case too for similar
reasoning. This has the side effect that you can't turn on keyboard apz without
doing a restart.
MozReview-Commit-ID: LxmofT2g7qs
This commit makes it so we initialize, send, and store a KeyboardMap for every
APZCTreeManager for later keyboard event processing.
This is a naive approach so it may be worth improving.
MozReview-Commit-ID: CYTbLL3wRlC
Now, nsIWidget::ExecuteNativeKeyBinding() isn't used by anybody for executing
edit commands. Instead, they need array of edit commands for the key
combination. So, the method should be renamed to GetEditCommands() and just
return edit commands as an array.
MozReview-Commit-ID: 4G0B1lJ8Lbe
People seem to be turning on this pref in the wild and generating crash reports
which are wasting time and energy of people who have better things to do.
MozReview-Commit-ID: 5VfjKaDluYJ
Prior to this patchset, we never hosted remote, scrollable content in widgets
other than toplevel and child windows, so all other widget types have APZ
disabled. Since we now need to host remote content in popup widgets, and would
like similar performance and behavior for those browsers as other remote
browsers, we also need to enable APZ for those widgets too.
MozReview-Commit-ID: AVDt9U5i2WK
PLayerTransaction's constructor was previously synchronous so we could
return a TextureFactoryIdentifier. This is quite reliably available
already in the case of opening a tab, due to RenderFrameParent knowing
which compositor it is attached to, so we can make the constructor
asynchronous.
In the top-level widget case, we add a new synchronous message to find
the TextureFactoryIdentifier.
Prior to this patchset, we never hosted remote, scrollable content in widgets
other than toplevel and child windows, so all other widget types have APZ
disabled. Since we now need to host remote content in popup widgets, and would
like similar performance and behavior for those browsers as other remote
browsers, we also need to enable APZ for those widgets too.
MozReview-Commit-ID: AVDt9U5i2WK
PLayerTransaction's constructor was previously synchronous so we could
return a TextureFactoryIdentifier. This is quite reliably available
already in the case of opening a tab, due to RenderFrameParent knowing
which compositor it is attached to, so we can make the constructor
asynchronous.
In the top-level widget case, we add a new synchronous message to find
the TextureFactoryIdentifier.
We only ever need to enable APZ for popups which contain remote content. In
theory, enabling it for other popups shouldn't hurt, but having it enabled
adds overhead that we'd rather avoid, and causes painting issues under some
circumstances.
Ideally, the painting issues should be fixed, but disabling APZ is a good
short term workaround, and we should try to avoid the unnecessary overhead
either way.
MozReview-Commit-ID: AOivnTQBWQh
There are several behaviors that we only need to apply to popups which are
known to contain remote content. And since those behaviors can cause issues
elsewhere, we need to be able to identify popups which should contain remote
content, and treat them specially, where appropriate.
MozReview-Commit-ID: EMFrSP8lZiD
IMEContentObserver may need to change notifications to send when TextInputProcessor begins input transaction. In current design, IMEContentObserver needs to retrieve IMENotificationRequests at every change. However, if nsIWidget returns a reference to its IMENotificationRequests, IMEContentObserver can call it only once.
For that purpose, this patch changes nsIWidget::GetIMENotificationRequests() to nsIWidget::IMENotificationRequestsRef() and make it return |const IMENotificationRequests&|. However, if the lifetime of the instance of IMENotificationRequest is shorter than the widget instance's, it's dangerous. Therefore, it always returns TextEventDispatcher::mIMENotificationRequests. TextEventDispatcher's lifetime is longer than the widget. Therefore, this guarantees the lifetime.
On the other hand, widget needs to update TextEventDispatcher::mIMENotificationRequests before calls of nsIWidget::IMENotificationRequestsRef(). Therefore, this patch makes TextEventDispatcher update proper IMENotificationRequests when it gets focus or starts new input transaction and clear mIMENotificationRequests when it loses focus.
Note that TextEventDispatcher gets proper requests both from native text event dispatcher listener (typically, implemented by native IME handler class) and TextInputProcessor when TextInputProcessor has input transaction because even if TextInputProcessor overrides native IME, native IME still needs to know the content changes since they may get new input transaction after that.
However, there may not be native IME handler in content process. If it runs in Android, PuppetWidget may have native IME handler because widget directly handles IME in e10s mode for Android. Otherwise, native IME handler is in its parent process. So, if TextInputHandler has input transaction in content process, PuppetWidget needs to behave as native event handler. Therefore, this patch makes PuppetWidget inherit TextEventDispatcherListener and implements PuppetWidget::IMENotificationRequestsRef().
MozReview-Commit-ID: 2SW3moONTOX
This just decouples nsAutoRollup from the widget class, which it isn't really
bound to anyway because the internal data is static. We'll need to be able to
use nsAutoRollup independently in the next patch.
MozReview-Commit-ID: 1dxSLTr4g1K
Bug 1343075 - 1a. Add TextEventDispatcherListener::GetIMEUpdatePreference; r=masayuki
Add a GetIMEUpdatePreference method to TextEventDispatcherListener to
optionally control which IME notifications are received by NotifyIME.
This patch also makes nsBaseWidget forward its GetIMEUpdatePreference
call to the widget's native TextEventDispatcherListener.
Bug 1343075 - 1b. Implement GetIMEUpdatePreference for all TextEventDispatcherListener; r=masayuki
This patch implements GetIMEUpdatePreference for all
TextEventDispatcherListener implementations, by moving previous
implementations of nsIWidget::GetIMEUpdatePreference.
Bug 1343075 - 2. Allow setting a PuppetWidget's native TextEventDispatcherListener; r=masayuki
In PuppetWidget, add getter and setter for the widget's native
TextEventDispatcherListener. This allows overriding of PuppetWidget's
default IME handling. For example, on Android, the PuppetWidget's native
TextEventDispatcherListener will communicate directly with Java IME code
in the main process.
Bug 1343075 - 3. Add AIDL interface for main process; r=rbarker
Add AIDL definition and implementation for an interface for the main
process that child processes can access.
Bug 1343075 - 4. Set Gecko thread JNIEnv for child process; r=snorp
Add a JNIEnv* parameter to XRE_SetAndroidChildFds, which is used to set
the Gecko thread JNIEnv for child processes. XRE_SetAndroidChildFds is
the only Android-specific entry point for child processes, so I think
it's the most logical place to initialize JNI.
Bug 1343075 - 5. Support multiple remote GeckoEditableChild; r=esawin
Support remote GeckoEditableChild instances that are created in the
content processes and connect to the parent process GeckoEditableParent
through binders.
Support having multiple GeckoEditableChild instances in GeckoEditable by
keeping track of which child is currently focused, and only allow
calls to/from the focused child by using access tokens.
Bug 1343075 - 6. Add method to get GeckoEditableParent instance; r=esawin
Add IProcessManager.getEditableParent, which a content process can call
to get the GeckoEditableParent instance that corresponds to a given
content process tab, from the main process.
Bug 1343075 - 7. Support GeckoEditableSupport in content processes; r=esawin
Support creating and running GeckoEditableSupport attached to a
PuppetWidget in content processes.
Because we don't know PuppetWidget's lifetime as well as nsWindow's,
when attached to PuppetWidget, we need to attach/detach our native
object on focus/blur, respectively.
Bug 1343075 - 8. Connect GeckoEditableSupport on PuppetWidget creation; r=esawin
Listen to the "tab-child-created" notification and attach our content
process GeckoEditableSupport to the new PuppetWidget.
Bug 1343075 - 9. Update auto-generated bindings; r=me
