Most event targets an element node even if the input occurs on a `Text`.
`EventStateManager`, `PresShell`, `PresShell::EventHandler`, etc use
the result of `nsIFrame::GetContentForEvent` result as-is or looking
for proper ancestor element by the caller selves.
So, I think there should be `GetEventTargetContent()` which solves the
target node kind automatically and in the same way. And also this patch
renames `nsIFrame::GetContentForEvent` to
`nsIFrame::GetEventTargetExplicitContent` for consistency with
`Event::mExplicitOriginalTarget`.
Finally, this patch changes the callers which retrieves a parent
`Element` if the result of `GetContentForEvent` is not an `Element` to
use the new `GetEventTargetContent`.
The following patches make each caller of `GetContentForEvent` marked
with "FIXME" comment fix one by one.
Differential Revision: https://phabricator.services.mozilla.com/D297848
Most event targets an element node even if the input occurs on a `Text`.
`EventStateManager`, `PresShell`, `PresShell::EventHandler`, etc use
the result of `nsIFrame::GetContentForEvent` result as-is or looking
for proper ancestor element by the caller selves.
So, I think there should be `GetEventTargetContent()` which solves the
target node kind automatically and in the same way. And also this patch
renames `nsIFrame::GetContentForEvent` to
`nsIFrame::GetEventTargetExplicitContent` for consistency with
`Event::mExplicitOriginalTarget`.
Finally, this patch changes the callers which retrieves a parent
`Element` if the result of `GetContentForEvent` is not an `Element` to
use the new `GetEventTargetContent`.
The following patches make each caller of `GetContentForEvent` marked
with "FIXME" comment fix one by one.
Differential Revision: https://phabricator.services.mozilla.com/D297848
Most callers of nsViewManager::GetRootWidget have a pres shell around
and don't need to care about views.
This is in preparation for bug 1994942, where we'll disconnect subdocs
from the view tree (and thus the view manager will not have the ability
to get a root widget).
Differential Revision: https://phabricator.services.mozilla.com/D269019
This patch tries to dispatch ePointerRawUpdate with
PresShell::EventHandler::DispatchPrecedingPointerEvent as same as usual
pointer events.
For using the path, this patch adds 2 internal events, eMouseRawUpdate
and eTouchRawUpdate which are never dispatched into the DOM because
PresShell::EventHandler::DispatchPrecedingPointerEvent will return false
for that and then the caller will stop handling the internal events.
There are 3 dispatchers of the internal raw update events.
One is PresShell::EnsurePrecedingPointerRawUpdate(). This dispatches the
internal event if and only if the coming event of PresShell::HandleEvent will
cause ePointerMove. The reason why PresShell::HandleEvent handles the
preceding raw-update event is, we should support ePointerRawUpdate events
for synthesized events for tests (in-process ones) and in the main process.
Additionally, if a pointerrawupdate event may destroy the target <iframe>.
In such ase, the following pointermove may need to be dispatched on its parent
window or another <iframe> window. Therefore, we need to dispatch the
internal raw update event before considering the target window (PresShell) and
handling the capturing element.
The others are BrowserChild::RecvRealMouseMoveEvent and
BrowserChild::RecvRealTouchMoveEvent. They dispatch the internal events
when they won't dispatch the received event immediately to coalesce with further
similar input.
For avoiding to dispatch the internal event for same source event, this adds
WidgetPointerHelper::convertToPointerRawUpdate member to check it in
PresShell::HandlePrecedingPointerRawUpdate.
Differential Revision: https://phabricator.services.mozilla.com/D243404
This patch tries to dispatch `ePointerRawUpdate` with
`PresShell::EventHandler::DispatchPrecedingPointerEvent` as same as usual
pointer events.
For using the path, this patch adds 2 internal events, `eMouseRawUpdate`
and `eTouchRawUpdate` which are never dispatched into the DOM because
`PresShell::EventHandler::DispatchPrecedingPointerEvent` will return `false`
for that and then the caller will stop handling the internal events.
There are 3 dispatchers of the internal raw update events.
One is `PresShell::EnsurePrecedingPointerRawUpdate()`. This dispatches the
internal event if and only if the coming event of `PresShell::HandleEvent` will
cause `ePointerMove`. The reason why `PresShell::HandleEvent` handles the
preceding raw-update event is, we should support `ePointerRawUpdate` events
for synthesized events for tests (in-process ones) and in the main process.
Additionally, if a `pointerrawupdate` event may destroy the target `<iframe>`.
In such ase, the following `pointermove` may need to be dispatched on its parent
window or another `<iframe>` window. Therefore, we need to dispatch the
internal raw update event before considering the target window (`PresShell`) and
handling the capturing element.
The others are `BrowserChild::RecvRealMouseMoveEvent` and
`BrowserChild::RecvRealTouchMoveEvent`. They dispatch the internal events
when they won't dispatch the received event immediately to coalesce with further
similar input.
For avoiding to dispatch the internal event for same source event, this adds
`WidgetPointerHelper::convertToPointerRawUpdate` member to check it in
`PresShell::HandlePrecedingPointerRawUpdate`.
Differential Revision: https://phabricator.services.mozilla.com/D243404
The Pointer Events spec defines that:
> Authors can prevent the firing of certain compatibility mouse events by
> canceling the pointerdown event (if the isPrimary property is true).
> <snip>
> Note, however, that this does not prevent the mouseover, mouseenter, mouseout,
> or mouseleave events from firing.
https://w3c.github.io/pointerevents/#the-pointerdown-event
The other browsers conform to this. Therefore, we should stop dispatching
compatibility mouse events only if the preceding `pointerdown` is consumed by
content. I.e., we need to keep dispatching touch events and `click` etc which
indicate what should happen on the element.
Currently, `APZEventState` does not manage whether the preceding `pointerdown`
is canceled or not. So, it dispatches compatibility mouse events via
`APZCCallbackHelper` after the consumed pointer is removed. Therefore, we
need to make it manage whether the preceding `pointerdown` of the first touch
is consumed or not and `APZCCallbackHelper` needs an option to dispatch the
compatibility mouse events only to chrome (they are required to dispatch
`click` etc).
However, if `APZEventState` is not available like test API used in the
remote process, `TouchManager` needs to manage it instead of `APZEventState`.
I don't think only `TouchManager` should manage it because `APZEventState`
manages complicated state of touch gestures and that can know whether the
synthesizing compatibility mouse events related to the consumed `pointerdown`
or not strictly. Therefore, this patch makes the `TouchManager` state used
only in the path handling synthesized events for tests.
Differential Revision: https://phabricator.services.mozilla.com/D208706
As far as investigating the behavior of the other browsers, touch events are
dispatched the same target as the preceding `pointerdown` even after the target
is removed from the DOM tree. However, the following pointer events are
dispatched on the target as usual (i.e., the element under the pointer except
when the pointer is captured). However, our code stops handling touch events
if the preceding `pointerdown` removes the target and not dispatching
`touchstart` causes not dispatching the following touch events so that no
`click` event is fired.
This patch makes the touch event dispatching path work without frame and
keep handling even with an orphan event target.
Differential Revision: https://phabricator.services.mozilla.com/D202811
HTMLSelectEventListener changes are needed, since currently that code works somewhat by accident given that
mTime often contains totally bogus values, like PR_IntervalNow(). Those changes then reveal issues also in
browser_editAddressDialog.js.
Differential Revision: https://phabricator.services.mozilla.com/D165618
We don't handle the first touchmove event differently, so I think we should do
the same thing for pointermove event, otherwise, we might fire a pointermove event
without a touchmove event for the first touch action after touchstart if the touch
postition isn't changed.
Depends on D152152
Differential Revision: https://phabricator.services.mozilla.com/D152153
We don't handle the first touchmove event differently, so I think we should do
the same thing for pointermove event, otherwise, we might fire a pointermove event
without a touchmove event for the first touch action after touchstart if the touch
postition isn't changed.
Depends on D152152
Differential Revision: https://phabricator.services.mozilla.com/D152153
Currently, checking whether an `EventTarget` is `nsINode` (or its concrete
classes) or not requires a QI, but it's expensive and used a lot while we
handle each event. Therefore, it'd be nicer for creating a virtual method,
`EventTarget::IsNode()` and use it for the check.
If trying to convert `EventTarget` to a concrete class, it may require two
virtual method calls. I'm not sure whether it's cheaper than a QI, but at
least, it won't depend on the UUID check order of `QueryInterface()` when
multiple interfaces are implemented.
Differential Revision: https://phabricator.services.mozilla.com/D129781
This patch doesn't change any user-observable behavior.
StaticAutoPtr lets us remove a handful of explicit 'delete' statements, by
making deletion happen automatically when these variables are cleared.
Differential Revision: https://phabricator.services.mozilla.com/D127336
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
The only thing in nsIFrame.h that was using it was the implementation
of a templated method, which could be moved to nsIFrameInlines.h.
Depends on D91504
Differential Revision: https://phabricator.services.mozilla.com/D91505
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
This patch assumes that only element node can have content node. I.e., we
won't hit the following `MOZ_ASSERT`:
```
Element* element = nullptr;
nsIContent* content = aContent;
while (content) {
if (content->IsElement()) {
element = content->AsElement();
break;
}
content = content->GetParent();
}
MOZ_ASSERT(!content || content == element || content->GetParent() == element);
```
Differential Revision: https://phabricator.services.mozilla.com/D63308
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
Masayuki Nakano