Note

• This bug happens when the videos have different formats.
• Please look at the attached gif.

Affected versions

• Firefox 74.0b6
• Firefox 75.0a1

Affected platforms

• Ubuntu 18 x64

Steps to reproduce

1. Go to a video on youtube (e.g: https://www.youtube.com/watch?v=R7A1mIdiheE)
2. Click on the Picture-in-Picture button.
3. From the video controls click on the next song.
4. From the browser controls click on the "Go back page" button.

Expected result

• The video has the same dimensions as in step 2.

Actual result

• The video gets smaller.

Regression range

• If it's a regression I will try to find it as soon as possible.

Hey Mark,

I seem to recall us considering this scenario when you were working on the window resizing bits for PiP... was this case not covered somehow?

So I poked around at this on linux a little, added some dump calls with the expected size and position combinations and the math seems to add up correctly, but sometimes the window will end up moving/shrinking. Seems like the size/position isn't ending up as what PictureInPicture.jsm is requesting, I tried moving the window away from the edge of the screen to see if it was moving off the screen and being recalculated but that didn't seem to fix it. This still happens intermittently.

We have tests for this, but they were originally disabled on linux [1] since the resizing wasn't implemented, they weren't enabled again when the resizing patch landed. I tried running the tests on linux but they all fail since it can't decode the video file for some reason.

We should look at enabling that test file on linux, I'm guessing it would have intermittent failures right now though.

[1] https://searchfox.org/mozilla-central/rev/96f1457323cc598a36f5701f8e67aedaf97acfcf/toolkit/components/pictureinpicture/tests/browser.ini#35-36

Poked a little more and it looks like the win.moveTo(left, top) call [1] is basically being ignored. We're calculating the new expected window size and position then calling win.resizeTo(width, height); immediately followed by win.moveTo(left, top). I wrapped the win.moveTo() call in win.setTimeout(() => win.moveTo(...), 100) and it started working. Adding 500ms timeouts to the tests made them pass.

@stransky is there some other way we should be resizing and moving this window at the same time or do you have any idea why the win.moveTo() call is being ignored?

[1] https://searchfox.org/mozilla-central/rev/96f1457323cc598a36f5701f8e67aedaf97acfcf/toolkit/components/pictureinpicture/PictureInPicture.jsm#505-507

Yes, Linux/Gtk uses async resize. I'll look at it.

The product::component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Martin, could you please set the priority flag? Is it still P3?

I can reproduce that on Fedora 32/X11 too. Works ok on Wayland.

https://hg.mozilla.org/mozilla-central/rev/0a6d64975cfa

Hello,

This issue is still reproducible on Firefox 76.0a1 (2020-04-02).
Here is a screenrecording with the issue: https://drive.google.com/file/d/1gh8Zugbs89vWbPV-kfhoYKrb5OGJ1N3c/view?usp=sharing

(In reply to Maria Berlinger [:maria_berlinger], Release Desktop QA from comment #12)

Hello,

This issue is still reproducible on Firefox 76.0a1 (2020-04-02).
Here is a screenrecording with the issue: https://drive.google.com/file/d/1gh8Zugbs89vWbPV-kfhoYKrb5OGJ1N3c/view?usp=sharing

And which distro/DE do you run?

Sorry that I forgot to mention, Ubuntu 18.04x64.

(In reply to Maria Berlinger [:maria_berlinger], Release Desktop QA from comment #14)

Sorry that I forgot to mention, Ubuntu 18.04x64.

Can you set "widget.use-aspect-ratio" to false and retest please?
Thanks.

By creating the "widget.use-aspect-ratio" and set it to false, the issue is no more reproducible.

Hello

Martin, do you think is worth filling another bug or to reopen this one, because the “widget.use-aspect-ratio" pref is not set by default on false and the issue still reproduces.

(In reply to Maria Berlinger [:maria_berlinger], Release Desktop QA from comment #17)

Hello

Martin, do you think is worth filling another bug or to reopen this one, because the “widget.use-aspect-ratio" pref is not set by default on false and the issue still reproduces.

That's really up to you, I don't have a strong opinion here.

When widget.use-aspect-ratio is set, keeping window aspect radio is disabled so the window is more difficult to resize by mouse cursor - you need to keep the aspect manually.

But it also fixes this bug and we can revert Bug 1624921 (PIP mode is switched back to system decorations) which fixes Bug 1622203.

Based on the fact that "widget.use-aspect-ratio" = false pref isn't by default in Firefox (you should add it manually) this issue is still reproducible and the user will be hit by this problem, so in my humble opinion we should reopen this bug based on this assessment.

I wonder if a patch from Bug 1683075 can help here.

This issue no longer occurs, when using the steps in comment 0, however, the PiP has suffered a redesign in the meantime and other similar issues still reproduce today. (ex. bug 1759537)

This being considered, I will close this report as worksforme.