1686390 - hit testing on css transform behaves differently than Chrome

Status: RESOLVED DUPLICATE of bug 1517388

(Core :: Web Painting, defect)

Description

[trusktr]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36

Steps to reproduce:

Visit and see the demo in https://stackoverflow.com/questions/65694472 in desktop Firefox.

Actual results:

Ignore the description regarding what appears to be a Chrome bug. Firefox has a different issue.

Try to drag the cube to the around the grid. Try it multiple times (drag, let go, drag, let go, ...).

While you are dragging the cube, notice that you can not successfully move it into the top-right cell.

This is because the pointerover event does not fire for that grid cell. That is grid cell 2 (zero-based, row-major order).

Also note if you move the cube to grid cell 4 (the middle cell), then you can not move the cube into cell 1 (top middle cell) or cell 2 (top right).

You can see in the console that there is no log output for the pointerover events for those cells.

Expected results:

We should be able to move the cube to any grid cell; or basically the pointerover event should fire for all cells.

Comment 1

[trusktr]

I fixed the pointerover issue in Chrome by not using pointerover, so the demo works flawlessly in Chrome now.

https://codepen.io/trusktr/pen/eYdPOKb

It still doesn't work in Firefox. For some reason, the top-right area of the grid is numb to the pointermove events.

Comment 2

[trusktr]

My guess is that CSS transforms are causing the hit testing to be wrong.

Comment 3

[trusktr]

I've no idea actually.

This similar demo behaves very different between Chrome and Firefox:

https://codepen.io/trusktr/pen/oNzaMeY

In Chrome, the placement of the cube when you drag is always correct.

In Firefox, the cube does not always want to go where you drag it.

Comment 4

[Shane Hughes [:aminomancer]]

for me, although none of the cells except top right seem completely off-limits, when i try to move the cube east it always seems to struggle. like it won't jump to the next cell to the right, but it will jump 2 cells to the right and then back 1 cell to the left. really weird. moving the cube west never seems to fail for me, for what that's worth

Comment 5

[Negritas Sergiu, Desktop QA]

Hello! I have managed to reproduce the issue using Firefox 86.0a1 (2021-01-18) on Ubuntu 20. I will add a component to this issue so one of our developers could look more into it. If it's not the right component please feel free to change it to an appropriate one.

Comment 6

[Brian Birtles (:birtles, Feb 26~ parental leave)]

No idea what is going on, but I don't see any transitions or animations in that demo. Moving to events for now. I did notice a lot of console errors though so that might be a good place to start.

Comment 7

[Edgar Chen [:edgar]]

This is not a pointer event issue, we don't even receive a mousemove event on the top-right area of the grid.

Comment 8

[Edgar Chen [:edgar]]

Attachment: test.html

minimal reproducible test script.

Comment 9

[Edgar Chen [:edgar]]

(In reply to Edgar Chen [:edgar] from comment #8)

Created attachment 9198263 [details]
test.html

minimal reproducible test script.

This is a similar setup as the test script in comment #1.

STR:

1. load test script
2. mouse moves on the green area that is overlapped with the red area.

Result in Firefox:
mousemove event is dispatched to the red content.

Result in Chrome:
mousemove event is dispatched to the green content.

But it seems our behavior makes more sense.

Comment 10

[Edgar Chen [:edgar]]

(Not sure if this is the right component for hit testing, feel free to send it back or move to the right component)

Comment 11

[Miko Mynttinen]

Based on Edgars reduced testcase, this is a webcompat issue that we have seen before in bug 1517388.

The issue is that hit testing behavior is not properly defined for 3D transformed elements. There is an open issue filed against the spec here https://github.com/w3c/csswg-drafts/issues/3997

Comment 12

[trusktr]

Thanks Edgar! I forgot about the transparent element I have in that example for the "camera" transform. I see how hovering on that transparent element blocks the pointer events from happening on the element underneath. It is easy to fix using pointer-events:none on that element.