Closed Bug 1620941 Opened 4 years ago Closed 4 years ago

PiP button z-Index

Categories

(Toolkit :: Video/Audio Controls, defect, P3)

Desktop
All
defect

Tracking

()

VERIFIED FIXED
mozilla76
Tracking Status
firefox-esr68 --- unaffected
firefox73 --- unaffected
firefox74 --- wontfix
firefox75 --- verified
firefox76 --- verified

People

(Reporter: udeepak010, Assigned: emilio)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(5 files)

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.

Component: General → Video/Audio Controls
Product: Firefox → Toolkit
Assignee: mconley → nobody
Blocks: videopip
Priority: -- → P3

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

Flags: needinfo?(emilio)

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.

Flags: needinfo?(emilio)

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?

Flags: needinfo?(emilio)

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.

Flags: needinfo?(emilio)

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

Flags: needinfo?(udeepak010)

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

Flags: needinfo?(udeepak010) → needinfo?(emilio)

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

Flags: needinfo?(emilio)

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

Flags: needinfo?(emilio)

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.

Regressed by: 1612318
Has Regression Range: --- → yes
Flags: needinfo?(emilio)
Assignee: nobody → emilio
Status: NEW → ASSIGNED

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

Depends on D66403

Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b4dc53cda583
Cleanup nsDOMWindowUtils::NodesFromRect. r=mconley
https://hg.mozilla.org/integration/autoland/rev/390774dc5231
Fix the visibility hit-testing code. r=miko
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla76

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.

Flags: needinfo?(aciure)

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).

Flags: needinfo?(aciure)

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
Attachment #9132585 - Flags: approval-mozilla-beta?
Attachment #9132584 - Flags: approval-mozilla-beta?
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

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

regression fix, approved for 75.0b5

Attachment #9132584 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9132585 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

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.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: