Steps to reproduce:

1. Create a video element with a z-index of 1
2. Create an backdrop, covering the whole page with a z-index of 2
3. Create a modal with a z-index of 3 with a button. *The button should come over the place where the blue Picture-in-picture toggle icon appears
4. Click on the button

Actual result:
Clicking on the button ignores the z-index and instead, clicks the PiP toggle icon

Expected Result:
Clicking on the button does not toggle the video player to PiP mode.

Works correctly on other browsers, since there is no such PiP toggle button for the other browsers

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Hey emilio, do you know why the nodesFromRect visibility check would be failing here?

The nodesFromRect visibility check seems to be doing as expected at least in that manual test-case. It only returns visible nodes, and PiP is testing for visibility of the <video>, not the toggle button. The video is actually visible (partially, at least).

I think PiP should check for visibility of the toggle, not the <video>, unless I'm missing something.

I guess hit testing should probably also intersect with the hit test area, that should probably also fix it...

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

The nodesFromRect visibility check seems to be doing as expected at least in that manual test-case. It only returns visible nodes, and PiP is testing for visibility of the <video>, not the toggle button. The video is actually visible (partially, at least).

True, the video is partially visible, but the point at which we're hit-testing (under the <button>), it is not. Am I misunderstanding how nodesFromRect is supposed to work here?

Hmm, so the visibility-hit-test code does try to handle this, but I'm not sure it's handling it particularly well.

In your reduced test-case the issue is that the button is a native button, so the painting code can't really know that it's opaque. If you style it with -moz-appearance: none; background: white or such you can see how the code starts working as expected.

But that seems like a different problem from the one in comment 0, where there is actually an opaque background, or so it seems. Anyhow, parting from the point that the visibility stuff is trying to deal with this, we should treat it as a bug.

Reporter, is there any chance you could provide an HTML example that shows the issue?

I can provide a limited access to you but would need to keep it private. Let me know how I can do that!

Please mail it to the email in bugzilla or emilio [at] mozilla.com. Thanks!

Sent you a mail on emilio [at] mozilla.com. You have all the information to reproduce the bug in there. If you need anything else, do let me know.

Hitting on the opaque purple background shouldn't open PIP

So this was regressed by bug 1612318, because it stopped creating nsDisplayBackgroundColor, and thus we can't tell whether the background is really opaque. So it seems it'd be a 74 regression.

Don't use nsDisplayEventReceiver for visibility hit testing, and fix the "stop
when we hit an opaque item" to actually work.

Depends on D66403

https://hg.mozilla.org/mozilla-central/rev/b4dc53cda583
https://hg.mozilla.org/mozilla-central/rev/390774dc5231

Would the fix be available in the latest nightly build? If yes, I would like to see how our website works once the bug has been fixed.

Once a push is merged to central it will be available in the nightly build in a maximum of 24 hours (or you can check when the nighly builds run and it will be available afterwards).

Comment on attachment 9132585 [details]
Bug 1620941 - Fix the visibility hit-testing code. r=miko,mattwoodrow

Beta/Release Uplift Approval Request

• User impact if declined: PiP button incorrectly shows up / takes up clicks when it shouldn't.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: see attachments on the bug.
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Fixes the regression by going back to do what we were doing before, and also fixes some other edge cases. Relatively minor patch.
• String changes made/needed: none

Comment on attachment 9132584 [details]
Bug 1620941 - Cleanup nsDOMWindowUtils::NodesFromRect. r=mconley

regression fix, approved for 75.0b5

https://hg.mozilla.org/releases/mozilla-beta/rev/69904ea80d4e
https://hg.mozilla.org/releases/mozilla-beta/rev/849ee837ece8

I used the test case from comment #2 and I managed to reproduce the issue on Firefox 75 beta 4 under Win 10 64-bit.
Verified as fixed using latest Nightly 76.0a1 2020-03-17 and Firefox 75 beta 5 under Win 10 64-bit, Ubuntu 18.04 64-bit and Mac OSX 10.14.