Application window goes to full screen after video is sized to full screen
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
People
(Reporter: seanpub, Unassigned)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:93.0) Gecko/20100101 Firefox/93.0
Steps to reproduce:
Using a large monitor (mine is 3840x1080), place the Firefox application in the middle of the screen in any unmaximized configuration. Open Youtube and watch a video. Click on the video's "full screen" button on the YouTube video. When done watching the video, escape out of full screen.
Actual results:
Firefox has now been resized to the full screen of the monitor (3840x1080). It is not officially maximized, so you can't double click the title to get it back to its original size. You must resize the window manually by using the mouse. I'm using Gnome 40 on Ubuntu 21.10. This is a new defect -- it didn't occur in Gnome 3.38/Ubuntu 21.04. I confirmed that the same behavior doesn't happen using Chrome, so this isn't a general Gnome problem.
Expected results:
In the past, when you escape a maximized video, Firefox remains at its original window size. Only the video should maximize, not Firefox. At the very least, please actually "maximize" Firefox so that it is easy to double click it back to the original size.
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 2•3 years ago
|
||
I can't repro this on Wayland nor X (on Fedora). Is there any chance you could run:
pip3 install --user mozregression
MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --good 78
To figure out what caused it? (Guessing 78 was behaving correctly, but if it isn't then there's something about your setup that might be triggering this and we need to do more digging.
Followed your instructions and ran build 78. Worked as I expected it to there -- meaning that when I escape the video, Firefox was the correct/original size. Another note -- it looks like the new version of Ubuntu uses the snap version of Firefox. I wanted to disable and regenerate my profile to see if maybe that was the problem, but with snap, I don't know how to do that anymore. I did try to recreate the bug using a private window and it still happened. It's possible that it has something to do with snap. Let me know if I can do any other tests for you.
|
|
||
Comment 4•3 years ago
|
||
Can you attach the mozregression log? Does a build from https://nightly.mozilla.org work? Maybe it is snap specific indeed.
Apologies, I don't know where the log is, but if you tell me how to generate it and where it would live, I'd be happy to include it. There is a bit of text from stdopt, but it doesn't say much. I'll add it at the end of this comment.
More testing that I did: I deleted the snap version of firefox and installed the repo version instead. This allowed me to rename my profile and try it with a fresh profile. The bug occurs in both the snap version and the repo version, both with my original profile and with a brand new profile.
I tried the nightly build of 93 (it shows as 94.0a1 (2021-09-06)) using your mozregression instructions but I changed 78 to 93. That one worked as I expected it should. Firefox did not resize itself after the video. So there is something different between calling mozregression and the standard repo version.
Here's the standard output from the call in case that's the log you wanted:
xxxxx@xxxxxx:~/.mozilla$ MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --good 93
You should use a config file. Please use the --write-config command line flag to help you create one.
0:00.17 INFO: No 'bad' option specified, using 2021-10-17
0:00.63 INFO: Using date 2021-09-06 for release 93
0:01.10 INFO: Testing good and bad builds to ensure that they are really good and bad...
0:01.10 INFO: Downloading build from: https://archive.mozilla.org/pub/firefox/nightly/2021/09/2021-09-06-21-42-43-mozilla-central/firefox-94.0a1.en-US.linux-x86_64.tar.bz2
===== Downloaded 100% =====
0:04.10 INFO: Running mozilla-central build for 2021-09-06
0:11.32 INFO: Launching /tmp/tmpd0eik__m/firefox/firefox
0:11.32 INFO: Application command: /tmp/tmpd0eik__m/firefox/firefox -profile /tmp/tmpwg0324m6.mozrunner
0:11.33 INFO: application_buildid: 20210906214243
0:11.33 INFO: application_changeset: aca153106940b800cac068609f552fc82b2ba2d1
0:11.33 INFO: application_name: Firefox
0:11.33 INFO: application_repository: https://hg.mozilla.org/mozilla-central
0:11.33 INFO: application_version: 94.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): exit
0:21.33 INFO: To resume, run:
0:21.33 INFO: /home/xxxxx/.local/bin/mozregression --repo=mozilla-central --good=2021-09-06 --bad=2021-10-17
| Comment hidden (obsolete) |
Work around discovered! I removed both the repo and the snap version of firefox and downloaded the TAR from firefox.com. After signing into a new profile, the application works as expected for me. This is an acceptable workaround to me. It looks like the Ubuntu repo/snap versions are different from the official firefox version.
Please let me know if you still want me to run the logs or if this is enough for you to close/push it downstream.
No, not in my opinion. Both the snap AND the standard ubuntu repo version of Firefox have this problem. I think whatever "magic" Ubuntu adds to Firefox caused the issue. The standard tarred version from firefox.com works correctly.
|
||
Comment 10•3 years ago
|
||
Can you try Wayland backend? Run upstream Firefox with MOZ_ENABLE_WAYLAND=1 env variable please.
Thanks.
|
Reporter | |
Comment 11•3 years ago
|
||
The bug does occur when I ran the following at 93. It also occurred when I ran the same 78. Not sure why it doesn't happen when I use the tarred version from firefox.com?
MOZ_ENABLE_WAYLAND=1 MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --good 93
You should use a config file. Please use the --write-config command line flag to help you create one.
0:00.37 INFO: No 'bad' option specified, using 2021-10-19
0:00.96 INFO: Using date 2021-09-06 for release 93
0:02.62 INFO: Testing good and bad builds to ensure that they are really good and bad...
0:02.62 INFO: Downloading build from: https://archive.mozilla.org/pub/firefox/nightly/2021/09/2021-09-06-21-42-43-mozilla-central/firefox-94.0a1.en-US.linux-x86_64.tar.bz2
===== Downloaded 100% =====
0:06.46 INFO: Running mozilla-central build for 2021-09-06
0:13.68 INFO: Launching /tmp/tmp44rdmzbb/firefox/firefox
0:13.68 INFO: Application command: /tmp/tmp44rdmzbb/firefox/firefox -profile /tmp/tmpby7j29ao.mozrunner
0:13.69 INFO: application_buildid: 20210906214243
0:13.69 INFO: application_changeset: aca153106940b800cac068609f552fc82b2ba2d1
0:13.69 INFO: application_name: Firefox
0:13.69 INFO: application_repository: https://hg.mozilla.org/mozilla-central
0:13.69 INFO: application_version: 94.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): good
|
|
||
Comment 12•3 years ago
|
||
Is MOZ_ENABLE_WAYLAND=1 the difference?
|
|
Reporter | |
Comment 13•3 years ago
|
||
Yes, that was the only difference when I ran the commands.
"MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --good 93" works as expected.
"MOZ_ENABLE_WAYLAND=1 MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --good 93" has the bug.
|
|
||
Comment 16•3 years ago
|
||
(In reply to mb from comment #15)
So we use xwayland for now?
Not sure what do you mean. X11/Xwayland is default and Wayland is used only when MOZ_ENABLE_WAYLAND is set.
|
||
Comment 17•3 years ago
|
||
Oh. I figured since Fedora Firefox was on Wayland by default that the Mozilla tarball would be too
Description
•