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
--HG--
extra : rebase_source : bc4c6417e77461634263defb88e67ed5036c454e
It has no users in mozilla-central or comm-central. This also lets us remove
nsBaseWidget::GetCursor().
--HG--
extra : rebase_source : 3875ce37c78f82285c4e5dbd8133e9ae3dafa0de
Additionally, do not call RegisterDragDrop for hidden windows.
MozReview-Commit-ID: Fv8j9FntGGT
--HG--
extra : rebase_source : fccbc576887d000805da8ac915d16fc4fddfeceb
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
--HG--
extra : rebase_source : 4581fa63aa3a9f32a8dc2672015a35b9be01b20f
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
--HG--
extra : rebase_source : c482816ecbaec0a889d817851ee15be186b2a49c
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
--HG--
extra : rebase_source : fbc7e311d83aab3b38fdd5c1b5c24d85458eb77b
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
--HG--
extra : rebase_source : ce0f2ca029d951a9c65ec1482e065b6695793133
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
--HG--
extra : source : 9430d123b19e0ac551c6048bb044fcfa22d13e45
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
--HG--
extra : rebase_source : 719d29efd80498b824fee03a5be1c1fd05c83074
extra : histedit_source : 7ad71a19782fc6dd203207afbdc7a73a936b3e04
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
--HG--
extra : rebase_source : 016b80a2a209d4fb5b92bc3adb95bd2dbb4399e0
All reftests that are still failing with APZ enabled are annotated with
a bug number that is tracking the fix.
MozReview-Commit-ID: 8QU15LHVy1t
--HG--
extra : rebase_source : 71908ca38e96e0f6f5a341605e70c3f6670b9237
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
--HG--
extra : rebase_source : 4a5829281d59677c773950c34d91a1cd8074d243
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
--HG--
extra : rebase_source : fa2237835d842ddb118c6ba6096f6b703aef9d81
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
--HG--
extra : rebase_source : a9482d966b9d910fe0f989f2ff5daf49d60033c8
extra : histedit_source : 4c039c182535acdc690abbc8201db749169e9b80
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
--HG--
extra : rebase_source : a1636aebdea84235e57922226c64fb987a4937a7
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
--HG--
extra : rebase_source : 5ee9da422081098d8099a048c7704008a06a7241
