Note

• When the user Launches PiP in a Linux + Wayland session, changes its position, then closes and reopens it, he will notice that the PiP window will open a little bit smaller than it was previously displayed, AND it is positioned in the same (close to) top-left corner, even if it was previously placed elsewhere.

Affected versions

• Nightly v101.0a1
• Beta v101.0b1
• Release
• ESR

Affected platforms

• Ubuntu 22.04 LTS + Wayland Window Protocol
• Ubuntu 20.04 LTS + Wayland Window Protocol

Steps to reproduce

1. Launch browser.
2. Make sure:
   media.videocontrols.picture-in-picture.audio-toggle.enabled true
   media.videocontrols.picture-in-picture.display-text-tracks.enabled true
3. Load and play a video (ex https://www.youtube.com/watch?v=kaUemcqIQ-k)
4. Click the PiP toggle.
   Observe: The PiP is opened close to the top-left corner (bug 1757918, bug 1621261).
5. Drag it to another position on the screen.
6. Close it.
7. Re-open the PiP (on the same video or same video size/aspect ratio).

Expected result

• The PiP is displayed having the same size and position as previously customized.

Actual result

• The PiP is displayed close to the top-left corner AND the size is a little smaller than previously seen.

Regression range

• Not a recent regression.

Additional notes
*

Ranking this a little higher than previously. The size issue doesn't feel particularly bothersome, while the position change is quite annoying.

I'm also having this problem on a Kwin + Wayland session.

Worse yet, I used KDE Window Rules to work around this issue, but recently some update broke this and now the rules only apply for the 1st time I open the PIP window, and not subsequent times I open it.
It looks as if Firefox is reusing the same window, or changes it's name after it opens, so the rule does not apply.

The severity field for this bug is set to S4. However, the following bug duplicate has higher severity:

• Bug 1846818: S3

:mhowell, could you consider increasing the severity of this bug to S3?

For more information, please visit BugBot documentation.

I was able to run mozregression and narrowed down the build(s) where it seems the breakage happened.

12:54.40 INFO: Narrowed integration regression window from [ff79aa6f, bb54a9a1] (3 builds) to [ff79aa6f, f2877dc5] (2 builds) (~1 steps left)
12:54.40 INFO: No more integration revisions, bisection finished.
12:54.40 INFO: Last good revision: ff79aa6f7ba8605e7ea59acddd521284f75136e4
12:54.40 INFO: First bad revision: f2877dc596a5c7045290b04e4bfb8ac50ba6fda5
12:54.40 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ff79aa6f7ba8605e7ea59acddd521284f75136e4&tochange=f2877dc596a5c7045290b04e4bfb8ac50ba6fda5

(In reply to yosukematsumura from comment #6)

I was able to run mozregression and narrowed down the build(s) where it seems the breakage happened.

12:54.40 INFO: Narrowed integration regression window from [ff79aa6f, bb54a9a1] (3 builds) to [ff79aa6f, f2877dc5] (2 builds) (~1 steps left)
12:54.40 INFO: No more integration revisions, bisection finished.
12:54.40 INFO: Last good revision: ff79aa6f7ba8605e7ea59acddd521284f75136e4
12:54.40 INFO: First bad revision: f2877dc596a5c7045290b04e4bfb8ac50ba6fda5
12:54.40 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ff79aa6f7ba8605e7ea59acddd521284f75136e4&tochange=f2877dc596a5c7045290b04e4bfb8ac50ba6fda5

Disregard - I had the KDE window rules misconfigured; the application/Window class name changed from 'firefox-nightly' to 'firefox-nightly-autoland', which messed up my results. Retesting...

Ran it again with this result:

14:29.85 INFO: Narrowed integration regression window from [30738d53, 775a6521] (3 builds) to [4b1c6fc1, 775a6521] (2 builds) (~1 steps left)
14:29.85 INFO: No more integration revisions, bisection finished.
14:29.85 INFO: Last good revision: 4b1c6fc1fc0f3e664d546c4bf5c24f0c157bc2c5
14:29.85 INFO: First bad revision: 775a6521f77bd6dfb28ea80bb6ea016ad637ed6c
14:29.85 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4b1c6fc1fc0f3e664d546c4bf5c24f0c157bc2c5&tochange=775a6521f77bd6dfb28ea80bb6ea016ad637ed6c

Now the question is: Is this an intentional change from Mozilla, or a bug?
If it's intentional I guess we gotta bring this up on the KDE side.

@emilio - the pushlog from comment 8 references two bugs that you worked on. Do you know if they happen to be related or not?

This is not "intentional" as much as a known Wayland limitation, see bug 1870955.

(In reply to nf.pereira from comment #3)

Worse yet, I used KDE Window Rules to work around this issue, but recently some update broke this and now the rules only apply for the 1st time I open the PIP window, and not subsequent times I open it.
It looks as if Firefox is reusing the same window, or changes it's name after it opens, so the rule does not apply.

That would be a regression worth tracking down, but it's quite hard to believe that bug 1838045 really caused this. I can take a closer look at that tho.

How do you have your KDE window rules configured so I can try to reproduce that regression?

In any case let's track it on a different (KDE-specific probably) bug.