1923513 - fission hit testing incorrect with clip-path on top.

Status: RESOLVED FIXED

(Core :: Web Painting, defect, P2)

Description

[Emilio Cobos Álvarez (:emilio)]

Test-case would be in bug 1911251 comment 5. Here's with an added background and no opacity just to confirm the clip-path clips everything:

data:text/html,<div style="position: absolute;left: 0px;top: 0px;width: 100%; height: 100%; z-index: 100; clip-path: polygon(0px 0px, 100% 0px, 100% 0%, 0px 0%); background-color: red;"></div><iframe src="http://techno-barje.fr/fission/input"></iframe>

It seems we're not dealing with clip-path polygon regions at all in APZ? This case is even more egregious because everything ends up clipped, so the absolute-positioned element shouldn't be hittable at all.

As for why was that page doing something like that... I don't know?

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Same test-case with same-origin frame (works):

data:text/html,<div style="position: absolute;left: 0px;top: 0px;width: 100%; height: 100%; z-index: 100; clip-path: polygon(0px 0px, 100% 0px, 100% 0%, 0px 0%); background-color: red;"></div><iframe srcdoc="<input type=text>"></iframe>

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Oh, actually test-case in comment 0 works, so the opacity: 0 is needed after all. Maybe we're optimizing out the opacity: 0 incorrectly somehow?

Actual test-cases. Fission:

data:text/html,<div style="position: absolute;left: 0px;top: 0px;width: 100%; height: 100%; z-index: 100; clip-path: polygon(0px 0px, 100% 0px, 100% 0%, 0px 0%); opacity: 0;"></div><iframe src="http://techno-barje.fr/fission/input"></iframe>

Non-fission:

data:text/html,<div style="position: absolute;left: 0px;top: 0px;width: 100%; height: 100%; z-index: 100; clip-path: polygon(0px 0px, 100% 0px, 100% 0%, 0px 0%); opacity: 0;"></div><iframe srcdoc="<input type=text>"></iframe>

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:botond, could you have a look please?

For more information, please visit BugBot documentation.

Comment 4

[Botond Ballo [:botond]]

Marking as S2 because this blocks an S2.

Comment 5

[Botond Ballo [:botond]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)

Oh, actually test-case in comment 0 works, so the opacity: 0 is needed after all. Maybe we're optimizing out the opacity: 0 incorrectly somehow?

Interestingly, if I remove the background-color: red; from the test case in comment 0, such that there is neither a background color nor an opacity, the bug still reproduces.

Comment 6

[Botond Ballo [:botond]]

Attachment: Gecko + WR display list without background-color (bad)

Comment 7

[Botond Ballo [:botond]]

Attachment: Gecko + WR display list with background-color (good)

Attached some display list dumps. The main difference seems to be that in the working case (with background-color), the WebRender display list contains more detailed information related to the clip-path, which allows accurate hit testing to happen in the compositor.

Comment 8

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #7)

in the working case (with background-color), the WebRender display list contains more detailed information related to the clip-path, which allows accurate hit testing to happen in the compositor.

Specifically, in the working case we get an ImageMaskClip WebRender display item created here. In the broken case we don't get there because we early exit here.

Comment 9

[Hiroyuki Ikezoe (:hiro)]

Oops, I wasn't realizing Botond left some comments in this bug.

Anyways, I've identified that this return Nothing() is probably the culprit. The clip-path in question is empty, we need to properly set the empty clip-path, rather then Nothing().

Comment 10

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1923513 - Make ComputeClipForMaskItem return empty rect as it is rather than returning Nothing(). r?botond

There are two tests;

helper_fission_empty_clip.html is for this bug (bug 1923513), there's an
element covering over an OOP iframe but it has an empty clip-path, thus any
input event is not interefered by the element.

helper_fission_unresolved_clip.html is to make sure that this code change
doesn't regress unresolved clip cases, it's similar to above case but with an
unresolved clip-path, thus the OOP iframe isn't rendered, any input element
isn't reached to the iframe.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/de9ba51c4851
Make ComputeClipForMaskItem return empty rect as it is rather than returning Nothing(). r=botond

Comment 12

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/de9ba51c4851