Closed Bug 1777367 Opened 2 months ago Closed 2 months ago

At YouTube, the "Skip Ad" button overlaps the Picture-in-Picture button (especially in a fresh profile where picture-in-picture button auto-expands)

Categories

(Toolkit :: Picture-in-Picture, defect)

defect

Tracking

()

VERIFIED FIXED
104 Branch
Tracking Status
firefox104 --- verified

People

(Reporter: dholbert, Assigned: mconley)

References

Details

(Keywords: pm-triage-needed)

Attachments

(3 files)

STR:

  1. Start with a fresh Firefox profile.

  2. Visit some YouTube video, e.g. https://www.youtube.com/watch?v=_ieNRF9aeTU (Hopefully you get a pre-roll ad with a 5-second countdown and then a "skip ad" button. This is necessary to trigger this bug.)

  3. Once it's available, click the "Skip Ad" button -- specifically, if it overlaps Firefox's Picture In Picture overlay-button, click an area where they overlap.

EXPECTED RESULTS:

  • I'd like to skip the ad.

ACTUAL RESULTS:

  • If I clicked an area where the buttons overlapped, then the Picture-In-Picture button eats the click. So when I wanted to skip the ad, I instead get a popped-out PiP ad.
  • The first time I do this in a fresh profile, this is extremely likely to happen because our PiP button auto-expands to helpfully explain itself with some bonus text. Unfortunately this expanded button nearly entirely overlaps the "Skip ad" button.

See attached screencast showing this "first time in a fresh profile" experience. I hover/unhover the "Skip Ad" button a few times, and then finally I click it, and instead trigger PiP.

(mconley, I know you've got some familiarity with our PiP code & user-experience -- do you know if this is a known issue and if there's anything we can do here?)

Flags: needinfo?(mconley)
Attachment #9283530 - Attachment description: screencast of issue → screencast of issue in a fresh profile (where this is almost guaranteed to happen by accident when user clicks "skip ad")

Here's a screencast of the STR in a not-quite-fresh profile (where we don't show the PiP onboarding auto-expanding button UI anymore). (I just cleared cookies/history to make it more likely that I'd get served an ad again.)

The screencast doesn't capture my mouse pointer, so you can't see where I'm clicking -- I'm just clicking near the top of the word "Ad" in "Skip Ad", which happens to overlap the bottom of our PiP button, at least in the viewport-size that I'm using for YouTube here.

side note: if I use a larger browser window, e.g. maximized, then the video area gets a bit larger and there's no overlap between the buttons.

Also: in one of the times where I tried to repro this, the PiP button didn't appear at all until after I clicked "skip ad". That trivially avoids this problem, since they can't overlap if they're not on-screen at the same time; though I'm not sure if that was a weird one-off glitch or if that's our intended experience here.

Thanks, dholbert! It looks like we actually fixed this a while ago in bug 1681663 by setting a visibility threshold of 0.7 on YouTube: https://hg.mozilla.org/mozilla-central/annotate/2c36387fdef826323e1250034e22aaccf5b7a9e4/browser/extensions/webcompat/data/picture_in_picture_overrides.js#l57

I think that got accidentally overwritten by a WebCompat add-on import here: https://hg.mozilla.org/mozilla-central/annotate/6024fc83883324d666906b79dcffced20bbdc51a/browser/extensions/webcompat/data/picture_in_picture_overrides.js#l57

and we just never caught it until now. I'll write a patch to put the threshold back to 0.7.

Flags: needinfo?(mconley)
Assignee: nobody → mconley
Status: NEW → ASSIGNED

Unfortunately, the YouTube ad algorithm is conspiring to give me either unskippable ads, or no ads at all - so I can't determine if this 0.7 threshold is still sufficient. Is anybody else able to confirm if this value still does the job?

Ah, finally got one. 0.7 seems to do the job still.

Pushed by mconley@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/10b948f55364
Put YouTube's PiP toggle visibility threshold back to 0.7. r=kpatenio

Thanks, mconley!

See Also: → 1681663
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 104 Branch

Verified the fix on Nightly 104.0a1 (20220704214252)

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.