Black screen in fullscreen mode
Categories
(Core :: Graphics, defect)
Tracking
()
People
(Reporter: williamzijl7, Unassigned)
Details
Attachments
(1 file)
|
38.67 KB,
text/plain
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:93.0) Gecko/20100101 Firefox/93.0
Steps to reproduce:
Be on (Arch) Linux, uses X11, Nvidia GPU, using KDE.
Open up a new profile on Firefox Nightly.
Goes to any youtube video or any website that utilized the fullscreen API.
Use the fullscreen mode of youtube or from the website that allows this
Actual results:
The whole window's screen is rendered in a black window.
Mouse events still works(hover icon is shown and buttons are still usable and click-able whereby js is fired).
When pressing escape(or clicking the fullscreen button again(if you know where to find it on the screen) will still have your whole Firefox Nightlyh window rendered as a black window, but if you move the window it will be rendered like it should.
Expected results:
See the youtube video/website in fullscreen.
Comment 1•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Graphics' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 2•4 years ago
|
||
Hi, thank you for the bug report.
Could you please attach a copy of your about:support information to this bug?
Do you know whether this used to work correctly? If so, could you please try running mozregression to find out what broke it?
On Linux it is easiest to use the command line:
pip install --user mozregression
mozregression --good 90
(Instead of 90 use the release on which it last worked correctly)
This will download and run a series of versions of firefox. For each one, answer "good" or "bad" and it will eventually tell you what change has caused this bug. Please let me know if you need any help with that.
Thanks!
| Reporter | ||
Comment 3•4 years ago
|
||
| Reporter | ||
Comment 4•4 years ago
|
||
Hi, thanks for taking a look!
I was trying to run a mozregression, as I do know it only started ~1 week ago and waited a little before reporting as it doesn't seem that uncommon to have something broken but fixed after a few days. But for some reason doing that mozregression it seems to me that it for some reason should've happend earlier? As it got narrowed down to: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=128804d2ba4c636a746189b53555c20139542583&tochange=1bbf4426ec872431da170b755f8dd8d275a3404f
Last good revision: 128804d2ba4c636a746189b53555c20139542583
First bad revision: 1bbf4426ec872431da170b755f8dd8d275a3404f
Which actually will make sense given that I'm using KDE but I don't have a damn clue why this bug is getting affected now since it's already been their for so long.
Just interesting to note: I somehow didn't got this bug on Firefox nightly yesterday after installing some new KDE packages as I did saw something interesting in their change log: https://bugs.kde.org/show_bug.cgi?id=440852 but happened just today again and even across different kernels and reboots. Also it only happens when the window is maximized, if it isn't the fullscreen just appears to be working as good.
| Reporter | ||
Comment 5•4 years ago
|
||
Hmm, it seems like KDE has introduced a regression: https://bugs.kde.org/show_bug.cgi?id=441904 not sure if it's still necessary to have this bug open.
Comment 6•4 years ago
|
||
Yes, the fact that you now see an old regression range, but in actual fact only started seeing the issue recently indicates that it is a KDE regression. Thanks for the information.
Description
•