New issue
Advanced search Search tips

Issue 733228 link

Starred by 2 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 3
Type: Bug



Sign in to add a comment

Inline elements with contenteditable="true" and pointer-events: none get focused on click

Reported by ickata...@gmail.com, Jun 14 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Steps to reproduce the problem:
Problem can be seen in this fiddle:
https://jsfiddle.net/ickata/e7uanbax/ 

What is the expected behavior?
There must be no difference in the behavior between inline and block elements. Both must not allow focus if there is pointer-events: none

What went wrong?
Inline elements ignore pointer-events: none and get focused on click. Block elements do not.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 58.0.3029.110  Channel: stable
OS Version: OS X 10.12.5
Flash Version:
 

Comment 1 by yosin@chromium.org, Jun 15 2017

Components: -Blink>Editing Blink>Input
Labels: OS-Windows
Status: Untriaged (was: Unconfirmed)
Route to Blink>Input. 

It seems we should check LayoutObject::VisibleToHitTesting() to determine
event target instead of "click" event handler, e.g. ClearButtonElement::DefaultEventHandler().

I'm not sure why pointe-events:none on DIV, or display:block(?), works correctly. Do we handle
pointer-events:none in another way?

LayoutObject::
  bool VisibleToHitTesting() const {
    return Style()->VisibleToHitTesting() && !IsInert();
  }

ComputedStyle::
  bool VisibleToHitTesting() const {
    return Visibility() == EVisibility::kVisible &&
           PointerEvents() != EPointerEvents::kNone;
  }

Cc: dtapu...@chromium.org yosin@chromium.org
Components: -Blink>Input Blink>Editing>Selection
Adjusting the above fiddle to report the mousedown/click target as per pointer-events:none, the target is always the body whether you click on the span or the div.
ie: document.addEventListener('click', function(e) { console.log('target is ' + e.target);});

// Result is body for both the span and div.

So the hit testing and the event dispatch is correct. I believe the problem is somewhere in the selection controller determining that it can do something with the cursor position.

yosin@ do you agree? If not I can dig further but it looks correct from the input point of view.


Comment 3 by yosin@chromium.org, Jun 16 2017

Status: Available (was: Untriaged)
>#c2, agree. It seems this is selection issue.

Comment 4 by yosin@chromium.org, Jan 10 2018

Labels: Pri-3
Project Member

Comment 5 by sheriffbot@chromium.org, Jan 10

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

Sign in to add a comment