New issue
Advanced search Search tips

Issue 710425 link

Starred by 1 user

Issue metadata

Status: Untriaged
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug


Show other hotlists

Hotlists containing this issue:
Fixing-touch


Sign in to add a comment

TouchEvent should not be fired at TextNode

Project Member Reported by hayato@chromium.org, Apr 11 2017

Issue description

TouchEvent should not be fired at TextNode

The context of the bug: See https://codereview.chromium.org/2807123002/

It looks that a kind of TouchEvent is fired at TextNode.
See https://cs.chromium.org/chromium/src/third_party/WebKit/Source/web/tests/WebViewTest.cpp?q=ShowUnhandledTapUIIfNeeded+package:%5Echromium$&l=3647

However, Touch Events specification says:

https://w3c.github.io/touch-events/#list-of-touchevent-types
> Trusted proximal event target types: Document and Element;

I am not 100% sure that what "Trusted proximal event target types" means, however, I believe that target types should not be a TextNode. That should be an Element in any case. That is consistent with other UI Events, such as Mouse Events.


 
Project Member

Comment 1 by bugdroid1@chromium.org, Apr 13 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/85e1871d673fb6c2e4bdb34dde02e5bb1ea896c6

commit 85e1871d673fb6c2e4bdb34dde02e5bb1ea896c6
Author: hayato <hayato@chromium.org>
Date: Thu Apr 13 08:53:14 2017

Fix the wrong non-element node handling in EventHanlder and MouseEventManager

{EventHandler,MouseEventManager} is storing a {clicked,tapped} node as Node*,
instead of Element*, that would be a bad practice. Actually, that has been the
cause of several wrong behaviors in Blink, such as:

1. Blink does NOT fire a click event when a clicked text node has been removed
   in mouseup.  This is wrong because a click event should be fired on an
   element node.  See [1] for details. This bug was just tentatively fixed at
   another CL [2].

2. Blink DOES fire a touch event on a non-element node.  This is wrong because
   TouchEvent specification says all kinds of touch events' event target types
  are limited to Document and Element [3].

To prevent these wrong behaviors, this CL does:
- Have EventHandlingUtil::ParentElementIfNeeded and use it everywhere so that
  we surely adjust a node to the appropriate element, at which an event should be
  fired.
- Replaces the usage of Node* to Element* as much as possible so that it rejects
  the wrong code at type level check.

- [1]: topmost event target;
  https://www.w3.org/TR/uievents/#topmost-event-target
- [2] https://codereview.chromium.org/2812613004
- [3]: Trusted proximal event target types are: Document and Element;
  https://w3c.github.io/touch-events/#list-of-touchevent-types

BUG= 708394 ,710425

Review-Url: https://codereview.chromium.org/2807123002
Cr-Commit-Position: refs/heads/master@{#464344}

[modify] https://crrev.com/85e1871d673fb6c2e4bdb34dde02e5bb1ea896c6/third_party/WebKit/LayoutTests/fast/events/touch/gesture/gesture-tap-frame-scrollbar-expected.txt
[modify] https://crrev.com/85e1871d673fb6c2e4bdb34dde02e5bb1ea896c6/third_party/WebKit/Source/core/input/EventHandler.cpp
[modify] https://crrev.com/85e1871d673fb6c2e4bdb34dde02e5bb1ea896c6/third_party/WebKit/Source/core/input/EventHandlingUtil.cpp
[modify] https://crrev.com/85e1871d673fb6c2e4bdb34dde02e5bb1ea896c6/third_party/WebKit/Source/core/input/EventHandlingUtil.h
[modify] https://crrev.com/85e1871d673fb6c2e4bdb34dde02e5bb1ea896c6/third_party/WebKit/Source/core/input/GestureManager.cpp
[modify] https://crrev.com/85e1871d673fb6c2e4bdb34dde02e5bb1ea896c6/third_party/WebKit/Source/core/input/MouseEventManager.cpp
[modify] https://crrev.com/85e1871d673fb6c2e4bdb34dde02e5bb1ea896c6/third_party/WebKit/Source/core/input/MouseEventManager.h

Project Member

Comment 3 by sheriffbot@chromium.org, Apr 19 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: Hotlist-DesktopUIToolingRequired Hotlist-DesktopUIChecked
*** UI Mass Triage***

Sign in to add a comment