There are two issues in our current setup
1) Input events which are occurring in the same tab are going to be lost
because sync XHR. We have event handling suppression for synx XHR, so input
events are going to be discarded.
2) Input events that are happening in another tab (same process as the
synx XHR tab) are not going to be delayed. This is not correct since
sync XHR should block the Javascript execution.
This patches fixes the above cases for when both TaskController and e10s are
enabled by suspending the InputTaskManager during sync XHR, which
delays the input event handling and keeps the events around.
Differential Revision: https://phabricator.services.mozilla.com/D90780
This patch is generated via the rename functionality in my editor; add
`mozilla::` prefix to `OverflowAreas` in headers; and remove the
`OverflowType` alias added in Part 1.
Differential Revision: https://phabricator.services.mozilla.com/D97235
Similar to the optional aContainingBlockSize parameter, both border and
padding should use logical coordinates in ReflowInput::mFrame's writing
mode.
Table frames that need to override border and padding can be simplified a bit.
However, DR_init_constraints_cookie and DR_init_offsets_cookie become more
complex, but they're only for debugging. I'm not planning to update their
internal APIs.
Differential Revision: https://phabricator.services.mozilla.com/D95369
This should make the optimization landed earlier in this bug apply for
some of the NotifyThemeChanged() calls in nsWindow.cpp which are causing
all the extra invalidations.
If we know that system colors/fonts didn't change, we can avoid doing a
bunch of reflow work and the patch from earlier in the bug can avoid
re-rasterizing images too.
Differential Revision: https://phabricator.services.mozilla.com/D94425
This is mostly a revert of the patch in bug 1425686 that removed the old
probe, but rebased to new code locations and clang-formatted. The histogram
entry is also updated with new bug numbers and fields.
The next patch will refine some of these telemetry recording points; the patch
is split into two for easier reviewing as this part is basically what landed
originally.
Differential Revision: https://phabricator.services.mozilla.com/D92995
when there is no composition, `IMEStateManager::HandleSelectionEvent()` calls
`TextComposition::HandleSelectionEvent()` with `BrowserParent` which is
retrieved from `aEventTargetContent` which is focused content in the main
process. This means that `eSetSelection` event is handled in root document
of the focused tab when there is no composition. However, following composition
events will go to focused `BrowserParent`, i.e., if an OOP iframe has focus
in the tab, `eSetSelection` event won't be handled in it. Therefore, IME
always fails to replace existing text with new composition.
This patch makes both `IMEStateManager::HandleSelectionEvent()` and
`PresShell::EventHandler::DispatchEventToDOM()` use
`IMEStateManager::GetActiveBrowserParent()` for sending both `eSetSelection`
and composition events to same process. Additionally, this patch make
`IMEStateManager::GetActiveBrowserParent()` returns
`IMEStateManager::sFocusedIMEBrowserParent` when it's set to non-nullptr
because native IME tries to modify the editor which enabled IME context.
On the other hand, for making the behavior safer, we should make
`eCompositionStart` event have replacing range optionally. I filed
bug 1669907 to change the design, but it requires several non-tiny patches.
Once we fix it, we can write automated tests for this simply, but without
the fix, I need to write too many lines with low level API, and it becomes
unnecessary after fixing the bug. Therefore, I give up to write a test
for this for now.
Differential Revision: https://phabricator.services.mozilla.com/D93053
This patch tries to mark root callers of `nsINode::GetSelectionRootContent()`
which calls `nsINode::GetAnonymousRootElementOfTextEditor()` as far as possible
(and reasonable).
It's used by `ContentEventHandler` so that a lot of methods of
`EventStateManager`, `ContentEventHandler`, `IMEContentObserver` which are main
users of it are also marked as `MOZ_CAN_RUN_SCRIPT`. I think that this is
reasonable.
On the other hand, it might not be reasonable to mark `IMEStateManager` methods
as `MOZ_CAN_RUN_SCRIPT` for initializing `IMEContentObserver` because
`IMEStateManager` may be able to initialize `IMEContentObserver` asynchronously
and its root callers are in XUL layout code. Therefore, this patch uses
`MOZ_CAN_RUN_SCRIPT_BOUNDARY` for `IMEStateManager` at least for now.
Differential Revision: https://phabricator.services.mozilla.com/D92730
This patch tries to mark root callers of `nsINode::GetSelectionRootContent()`
which calls `nsINode::GetAnonymousRootElementOfTextEditor()` as far as possible
(and reasonable).
It's used by `ContentEventHandler` so that a lot of methods of
`EventStateManager`, `ContentEventHandler`, `IMEContentObserver` which are main
users of it are also marked as `MOZ_CAN_RUN_SCRIPT`. I think that this is
reasonable.
On the other hand, it might not be reasonable to mark `IMEStateManager` methods
as `MOZ_CAN_RUN_SCRIPT` for initializing `IMEContentObserver` because
`IMEStateManager` may be able to initialize `IMEContentObserver` asynchronously
and its root callers are in XUL layout code. Therefore, this patch uses
`MOZ_CAN_RUN_SCRIPT_BOUNDARY` for `IMEStateManager` at least for now.
Differential Revision: https://phabricator.services.mozilla.com/D92730
The only caller passed in DisplayRelativeTo::ScrollFrame.
Removing this makes it easier to consolidate display port options
in a subsequent patch.
Differential Revision: https://phabricator.services.mozilla.com/D92014
The frame we pass to PageMove is used to extend the selection, we can't extend a selection outside of the document. The scrolling that takes place can still scroll scroll frames in parent documents afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D92176
The current formulation is inconsistent. If you call it with ScrollableDirection::Either it goes into nsLayoutUtils::GetNearestScrollableFrame which will return the first scroll frame with a non-hidden overflow. If you call it with any other ScrollableDirection it calls nsLayoutUtils::GetNearestScrollableFrameForDirection which returns the first scrollframe it finds that has non-hidden overflow AND has at least one dev pixel of scroll range.
So remove that function and call nsLayoutUtils::GetNearestScrollableFrameForDirection directly. This is a slight change of behaviour but it seems desirable for all callers.
Differential Revision: https://phabricator.services.mozilla.com/D91236
The problems that it causes that are referred to in the patch is that we use the vvoffset and GetScrollRangeForUserInputEvents to compute the scrollbar cur, min, and max attributes. If we have a non-zero vvoffset when we are zooomed backed out, GetScrollRangeForUserInputEvents will be a zero range and so the cur attribute (non-zero) will be larger than the max attribute (0).
This then causes nsSliderFrame::AttributeChanged to call ScrollByWhole at
https://searchfox.org/mozilla-central/rev/30e70f2fe80c97bfbfcd975e68538cefd7f58b2a/layout/xul/nsSliderFrame.cpp#204
Which we definitely do not want.
Differential Revision: https://phabricator.services.mozilla.com/D90372
Otherwise the only time it gets set is when the ZoomConstraintsClient specifically sets it in response to one of the things that can change it. But if the scroll frame gets reconstructed and one of those things don't happen it will be wrong.
This shows up with desktop zooming scrollbars because we check mZoomableByAPZ (or WantAsyncScroll()) before we use the apz scroll path in ScrollFrameHelper::ScrollBy().
Differential Revision: https://phabricator.services.mozilla.com/D90384
Otherwise the only time it gets set is when the ZoomConstraintsClient specifically sets it in response to one of the things that can change it. But if the scroll frame gets reconstructed and one of those things don't happen it will be wrong.
This shows up with desktop zooming scrollbars because we check mZoomableByAPZ (or WantAsyncScroll()) before we use the apz scroll path in ScrollFrameHelper::ScrollBy().
Differential Revision: https://phabricator.services.mozilla.com/D90384
eTopLevel is reused in content process to indicates that the mouse leaves
the puppet widget rendering area, now we add a separated type, ePuppet, for it.
Differential Revision: https://phabricator.services.mozilla.com/D84748
