New issue
Advanced search Search tips

Issue 647594 link

Starred by 4 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Table rows are not returned from hit tests

Reported by messagec...@gmail.com, Sep 16 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36

Steps to reproduce the problem:
1. For an example reproduction, visit https://developer.chrome.com/extensions/api_index
2. Open console and run the following code. 
document.addEventListener( 'mousemove', e => {
  console.log( e.path );
  console.log( document.elementsFromPoint( e.clientX, e.clientY ) );
})
3. Mouse over some of the table rows and td elements and observe that sometimes tr and tbody are present in the path but not present in the z stack returned by elementsFromPoint.
4. Use DevTools to highlight those elements and observe that they are in fact present, non-zero size, and are under the moused over elements.
5. Further observe they do not have any potentially interacting characteristics such as pointer-events: none

What is the expected behavior?
All elements in the z-stack should be returned under the point.

As per spec: https://drafts.csswg.org/cssom-view/#dom-document-elementfrompoint

What went wrong?
elementsFromPoint apparently fails to report some elements that the spec appears to require it to report.

Did this work before? N/A 

Chrome version: 53.0.2785.116  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 23.0 r0

Is this a spec bug or an implementation  bug?
Or is there some other behaviour which is not described by this bug report and everything is OK?
 

Comment 1 by bokan@chromium.org, Sep 16 2016

Components: -Blink Blink>HitTesting Blink>Input
Labels: -OS-Windows Hotlist-Input-Dev OS-All
Status: Untriaged (was: Unconfirmed)
Thanks for the report.

Tried in Firefox and they at least return the <tr> element as well as an "HTMLTableSelectionElement". 
Owner: pdr@chromium.org
Interesting, we actually have a test [1] the verifies the table case and ensures we don't return tr, and td! Assigning to pdr@ who wrote that test to further triage.

[1] https://codesearch.chromium.org/chromium/src/third_party/WebKit/LayoutTests/fast/dom/elementsFromPoint/elementsFromPoint-table.html

P.S. note that event.path is not the same thing as elementsFromPoint. One is the hierarchy of nodes in DOM the other just all elements under the same point.
Interesting. I know the API difference. They're not zero sized, I wonder if
something in the spec says they shouldn't be returned.

Comment 4 by pdr@chromium.org, Sep 22 2016

Cc: pdr@chromium.org
Owner: ----
Status: Available (was: Untriaged)
Interesting find! elementsFromPoint just relies on the existing hit testing code which is also broken for table rows: http://jsbin.com/cutijur

This should be a pretty easy fix in LayoutTableSection::nodeAtPoint. Would someone on input or hit testing be able to look into it?

Comment 5 by pdr@chromium.org, Sep 22 2016

Summary: Table rows are not returned from hit tests (was: elementsFromPoint incorrectly omits some tags in the z stack)
FYI hit testing is part of the paint team now.
Components: -Blink>Input
Labels: -OS-All BugSource-User PaintTeamTriaged-20170425 OS-Android OS-Chrome OS-Linux OS-Mac OS-Windows
Project Member

Comment 9 by sheriffbot@chromium.org, Apr 26 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
Status: Available (was: Untriaged)

Sign in to add a comment