`PresShell::EventHandler::PrepareToDispatchEvent()` checked whether the
given event is a trusted event or an untrusted event, but
`PresShell::EventHandler::PrepareToDispatchOntextMenuEvent()` didn't so.
However, now, both of them don't need to check it. Therefore, we can merge
them.
Differential Revision: https://phabricator.services.mozilla.com/D24132
`PresShell::EventHandler` shouldn't be used to dispatch untrusted event.
However, it checks whether the given event is trusted or untrusted somewhere
and that makes the code harder to understand. So, it should check each event
only with `MOZ_ASSERT()` or `MOZ_DIAGNOSTIC_ASSERT()` instead. Then,
developers can trust the event is always a trusted event.
Differential Revision: https://phabricator.services.mozilla.com/D24131
This patch renames nsIPresShell::SetPendingVisualScrollUpdate() to
ScrollToVisual(), and adds an instant vs. smooth option.
SetPendingVisualScrollUpdate() still exists, as a helper for the instant case.
Differential Revision: https://phabricator.services.mozilla.com/D24553
`PresShell::EventHandler::PrepareToDispatchEvent()` checked whether the
given event is a trusted event or an untrusted event, but
`PresShell::EventHandler::PrepareToDispatchOntextMenuEvent()` didn't so.
However, now, both of them don't need to check it. Therefore, we can merge
them.
Differential Revision: https://phabricator.services.mozilla.com/D24132
`PresShell::EventHandler` shouldn't be used to dispatch untrusted event.
However, it checks whether the given event is trusted or untrusted somewhere
and that makes the code harder to understand. So, it should check each event
only with `MOZ_ASSERT()` or `MOZ_DIAGNOSTIC_ASSERT()` instead. Then,
developers can trust the event is always a trusted event.
Differential Revision: https://phabricator.services.mozilla.com/D24131
Oddly, when there is no frame and the handling event does not require a frame,
`PresShell::EventHandler::HandleEvent()` just clears
`mPresShell->mCurrentEventFrame` with nullptr before calling
`HandleEventWithCurrentEventInfo()`. This means that if event handler is
nested, old `mPresShell->mCurrentEventContent` is reused and
`mPresShell->mCurrentEventFrame` is forgotten. Therefore, it should push
nullptr as current event info instead.
Differential Revision: https://phabricator.services.mozilla.com/D24130
Currently the MobileViewportManager leaves somethings permanently changed
even after it is destroyed: it may have changed the resolution of
the Document, and it may have set a fixed size for the visual viewport.
Both of these changes need to be un-done to return to normal display of
the Document.
Differential Revision: https://phabricator.services.mozilla.com/D17999
Once nsIPresShell::SetVisualViewportSize is called, we currently have
no way to restore the default viewport sizing behavior. This corrects that.
We need the default behavior to get correctly-placed scrollbars when
turning off meta viewport handling in Responsive Design Mode panes.
Differential Revision: https://phabricator.services.mozilla.com/D20593
Currently the MobileViewportManager leaves somethings permanently changed
even after it is destroyed: it may have changed the resolution of
the Document, and it may have set a fixed size for the visual viewport.
Both of these changes need to be un-done to return to normal display of
the Document.
Differential Revision: https://phabricator.services.mozilla.com/D17999
Once nsIPresShell::SetVisualViewportSize is called, we currently have
no way to restore the default viewport sizing behavior. This corrects that.
We need the default behavior to get correctly-placed scrollbars when
turning off meta viewport handling in Responsive Design Mode panes.
Differential Revision: https://phabricator.services.mozilla.com/D20593
Now, other methods taking `aFrame` of `HandleEvent()` names the argument as
`aFrameForPresShell`. So, `HandleEvent()`'s `aFrame` should also be renamed.
This patch renames it and adds MOZ_CAN_RUN_SCRIPT and comment to
`nsIPresShell::HandleEvent()`.
This is the final patch for bug 1466208.
Differential Revision: https://phabricator.services.mozilla.com/D22463
In my understanding, `PresShell::EventHandler::HandleEvent()` may redirect
the event to another class or PresShell first. Otherwise, it computes
event target and sets current event info of mPresShell to it. Then, calls
`HandleEventInternal()` to dispatch the event. Then, `HandleEventInternal()`
may handle the event before dispatch, and/or prepare to dispatch, then,
finally dispatches the event and finalize the state of mPresShell and the
event. Therefore, `HandleEventInternal()` actually handles the event, but
the word, "internal" is not explicitly explain its different points from
`HandleEvent()`. Therefore, I think that `HandleEventWithCurrentEventInfo()`
is better name since `HandleEvent()` considers the current event info.
Differential Revision: https://phabricator.services.mozilla.com/D22462
Finally, we should move the last switch statement in `HandleEventInternal()`
to the new method. Then, `HandleEventInternal() does nothing complicated
things by itself.
Differential Revision: https://phabricator.services.mozilla.com/D22461
This is the part which actually handles the event. The new method should
notify EventStateManager of dispatching event before and after that, and
actually dispatch the event into the DOM.
Differential Revision: https://phabricator.services.mozilla.com/D22459
For making `PresShell::EventHandler::HandleEventInternal()` easier to read,
move the large switch statement for preparation into the new method.
Differential Revision: https://phabricator.services.mozilla.com/D21341
`PresShell::EventHandler::HandleEventInternal()` may handle `Escape` key before
dispatching it in some cases. This requires too many lines for somebody who
investigate the method for the other events. Therefore, this patch moves it
into the new method.
Additionally, this patch creates `WidgetKeyboardEvent::CanTreatAsUserInput()`
and `WidgetKeyboardEvent::ShouldInteractionTimeRecorded()` because we should
manage similar checks in one place (we already have
`WidgetKeyboardEvent::CanUserGestureActivateTarget()`). Finally, their
conditions are not enough for what the comment wants to do there since they do
not check some modifier keys. Therefore, this patch makes them check all
possible modifier keys too.
Differential Revision: https://phabricator.services.mozilla.com/D21340
The first switch statement of `PresShell::EventHandler::HandleEventInternal()`
has 2 jobs:
- Prepare something for specific event type.
- Record the preparation time of some types of events to telemetry.
This intermixed code is not easy to understand and somebody may add new
preparation after recording them. So, even though the preparation time
becomes worse a couple of nanoseconds, we should split those jobs.
The patch moves the latter job into the new method.
Differential Revision: https://phabricator.services.mozilla.com/D21339
Oddly, there are two trusted eMouseMove preparation code in
`PresShell::EventHandler::HandleEventInternal()`. One is in the `switch`
statement which is used only when `aEvent` is trusted. The other is after
`TouchManager::PreHandleEvent()` is called and after
`AutoHandlingUserInputStatePusher` is created. However, both of them do
nothing if the event is `eMouseMove`. Therefore, we can move the latter
into the former.
Differential Revision: https://phabricator.services.mozilla.com/D21338
If `Shift` state of `eContextMenu` event is active, we make it not fired on
web content. Additionally, if it's not time to open context menu, we shouldn't
dispatch it into the DOM. The new method prepare and check them.
Differential Revision: https://phabricator.services.mozilla.com/D21337
If `aEvent` requires frame but there is no event target,
`PresShell::EventHandler::HandleEventInternal()` just records the response
time. So, we can reduce one indent level in the big method.
Note that I'm not sure recording the response time in such case because
the *good* values may make the average and median better. But this is
out of scope of bug 1466208.
Differential Revision: https://phabricator.services.mozilla.com/D21336
`PresShell::EventHandler::HandleEventInternal()` needs to accumulate event
handling time per each event type. The handling start time needs to be
recorded before sending EventStateManager. Therefore, this patch makes the
helper class which is a stack class, records current time at construction
and calls `Telemetry::AccumulateTimeDelta()` at destruction automatically.
Differential Revision: https://phabricator.services.mozilla.com/D21335
`PresShell::EventHandler::HandleEventInternal()` recodes event handling
response performance with telemetry after it dispatches the event. We can move
it into new method simply.
Differential Revision: https://phabricator.services.mozilla.com/D21334
We really only have two sets of prefs, one for chrome-like documents
(stuff in chrome docshells + chrome-origin images), and one for the rest.
Differential Revision: https://phabricator.services.mozilla.com/D20946
The remaining part of `PresShell::EventHandler::HandleEvent()` does:
1. Handles the event at focused content.
2. Handles the event with given frame which is a frame for `mPresShell`.
For making them clearer, this patch moves them into new methods.
Differential Revision: https://phabricator.services.mozilla.com/D21197
If focused element is in another document,
`PresShell::EventHandler::HandleEvent()` needs to retarget the event to another
`PresShell`. This patch moves the case into new overload method,
`MaybeHandleEventWithAnotherPresShell()`.
Additionally, removes `PresShell::HandleRetargetedEvent()` and makes
`EventHandler::HandleRetargetedEvent()` non-public because the new method
is the only user of them.
Differential Revision: https://phabricator.services.mozilla.com/D21196
With splitting `HandleEvent()` a lot, it becomes more difficult to keep
managing each set of calling `PushCurrentEventInfo()` and
`PopCurrentEventInfo()`. So, `EventHandler` should have a helper class
to push and pop current event info into/from the stack.
Differential Revision: https://phabricator.services.mozilla.com/D21198
Most remaining code in `PresShell::EventHandler::HandleEvent()` is what computes
event target of the event which should be handled on focused content. This
patch moves the part to the new method.
Additionally, moves `nsIPresShell::gKeyDownTarget` to
`EventHandler::sLastKeyDownEventTargetElement` and make it use `StaticRefPtr`.
Finally, for using `Element*` instead of `nsIContent*`, changes the result type
of `Document::GetUnfocusedKeyEventTarget()` to `Element*`.
Differential Revision: https://phabricator.services.mozilla.com/D21195
nsIconChannel (for moz-icon:// images) is unsound, see bug 1438939.
nsMenuPopupFrame::Init is also unsound on mac, looks like...
I'll try to get them fixed on trunk, but it's not worth crashing release for
this IMO, given it's pre-existing. The assert in PresShell::~PresShell hopefully
avoids exploitable issues.
Differential Revision: https://phabricator.services.mozilla.com/D20945
When the event is not handled with coordinates and there is no frame for
`mPresShell`, `PresShell::EventHandler::HandleEvent()` handles the events
simpler than the case there is a frame. Therefore, this patch moves the
`else` block of `if (aFrame)` and reduce the indent of `if (aFrame)` case.
Differential Revision: https://phabricator.services.mozilla.com/D21194
Now, the block in HandleEvent(), which handles event using coordinates is
less than 200 lines. Perhaps, this is good amount to be split to a method.
This patch just moves the block to a new method.
Differential Revision: https://phabricator.services.mozilla.com/D21193
After dispatching pointer events, `PresShell::EventHandler::HandleEvent()`
updates event target only when the event is a touch event. We should do it in
a new method of `EventTargetData`.
Although I don't know why this is done in
`PresShell::EventHandler::DispatchPrecedingPointerEvent()`.
Differential Revision: https://phabricator.services.mozilla.com/D21192
Now, we can move the block dispatching preceding pointer event to separated
method. Then, we can hide the complicated retarget process after dispatching
a pointer event from HandleEvent().
Differential Revision: https://phabricator.services.mozilla.com/D21191
Currently, PresShell::EventHandler::HandleEvent() sets `overrideClickTarget`
only when Pointer Events is enabled and there is pointer capturing content,
and this is computed while dispatching a pointer event.
So, if we move it into EventTargetData, we can move the pointer event
dispatching block into a separated method and caller can receive it with
an EventTargetData instance which is anyway necessary to receive new
target frame after dispatching a pointer event.
Differential Revision: https://phabricator.services.mozilla.com/D21190
We cannot move each block into separated methods while computing EventTargetData
because we need to check capturing contents, etc. Therefore, only each block
should be moved to separated methods for now.
This moves a block which computes event target from point of the event. If
this can be moved to EventTargetData, it might be easier to understand, but
its helper method GetFrameToHandleNonTouchEvent() requires to access members
of EventHandler. Therefore, we need to treat EventTargetData as an out param
of the new method.
Differential Revision: https://phabricator.services.mozilla.com/D21189
