1749721 - "fission.autostart" - in fullscreen mode, video control pannel disappears and no longer goes back

Status: RESOLVED DUPLICATE of bug 1747409

(Core :: Graphics: WebRender, defect)

Description

[veron]

Attachment: image.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96.0

Steps to reproduce:

about:config → fission.autostart → true

Example open link https://www.kinopoisk.ru/film/1198811/ and play video Trailer in full-screen.

Actual results:

In full-screen mode, after the disappearance of the control panel, it no longer appears when moving with the mouse. Output only through the "Esc" button.

Expected results:

I was looking for this problem more than 5 hours to find this malfunction, I could not understand why it happens. The reason was found and provided in the "About: Config" setting (fission.autostart → true).

Comment 1

[veron]

When we switch "Fission.Autostart → False" the problem disappears.

Comment 2

[Edgar Chen [:edgar]]

This doesn't look like a recent regression as I could also reproduce this on 80.
And clicking on the video in fullscreen can not play or pause it, maybe something related to event dispatching? investigating...

Comment 3

[Edgar Chen [:edgar]]

Update what I found so far,

The video control and video are in different iframes, the layout is something like, top-level --iframe--> video control --iframe--> video.
And the video iframe will post messages to the video control iframe to update status. And I see some differences between Fission and non-Fission.

On non-Fission, when the video is not in fullscreen mode and the mouse is over video firame, the video control iframe will receive mouse status updates from video iframe, including mousemove, click .. etc. But once the video is in fullscreen mode, video control iframe will NOT receive mouse status updates via postMessage.

But on Fission, the video control iframe still receives the mouse updates from the video iframe even video in fullscreen. I also tried Chrome, Chrome behaves like non-Fission.

I guess the above differences might be related to this issue, but not sure.

Comment 4

[Edgar Chen [:edgar]]

Okay, in fullscreen mode, video control iframe creates a div over the video iframe

<div class="_34WPyF6 _1Gx9Olr L3bXota"></div>

And we expect the mouse event would dispatch to that div, instead of the video iframe.

On Chrome, if I remove pointer-events: auto; inherited from its parent element, the div becomes pointer-events: none;, and I got the same broken behavior.

So it seems like somehow the pointer-events: auto; doesn't work?
I will try if I can find a minimal test script.

Comment 5

[Edgar Chen [:edgar]]

Attachment: test.html

Comment 6

[Edgar Chen [:edgar]]

There was a similar bug on pointer-events: none before, see bug 1566599 comment #1.
So it seems like a hit-testing bug, :botond, would you be able to take a look? Thanks!

Comment 7

[Botond Ballo [:botond]]

The issue doesn't seem to be related to pointer-events: auto -- if I remove the pointer-events properties from the testcase, the behaviour is the same (mousemove events are logged in Fission mode, and not logged in non-Fission mode).

That said, it does look like a potential hit-testing bug. Will try to investigate a bit further.

Comment 8

[Botond Ballo [:botond]]

Attachment: Gecko+WR display list from root content process

Attached is a Gecko+WR display list from the root content process.

The Remote display item for the iframe comes before (meaning below) the CompositorHitTestInfo item for the class="foo" <div> which is supposed to capture the events.

However, the WebRender hit test results (which are ordered top to bottom) have items from the iframe at the top.

Comment 9

[Botond Ballo [:botond]]

The symptoms are very similar to bug 1747409. I suspect an issue in the same code, possibly even a duplicate.

Comment 10

[Botond Ballo [:botond]]

This is indeed fixed by bug 1747409.