fullscreen isn't fullscreen, it's screen.height-1
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
People
(Reporter: support, Unassigned, NeedInfo)
Details
Attachments
(5 files)
Bildschirmfoto vom 2024-04-14 20-00-58.png
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:124.0) Gecko/20100101 Firefox/124.0
Steps to reproduce:
Watching Netflix switching to fullscreen via button and/or F11
Actual results:
the playbackwindow grows to fullscreen, but the TOP Pixelline ( Y=1 (not 0) as it looks ) shows the Desktopbackground.
The attached picture shows the entire desktop display, move to Y=1 and zoom in, you will notice a blue textured line. This should not be there at all.
This happens repeatable every time for a while now.
WORKAROUND: switch Background in Desktop to black, so it does not disturb so much.
Expected results:
no top background should be visible.
|
||
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Graphics' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
If you asked "me":
yes, it's a real screenshot on a dual monitor 1920x1080 Fedora Linux 38 system. The blueline comes from the "blue sea" background of the desktop.
If your asked a co-dev:
could be a misaligned drawing pane, as the window frame before the fullscreen() does perfectly max out the screen, with no visual blue line on top or in the frame.
I would search first in the algorithm that resizes the image from window framed to borderless. It looks like it stops resizing when it hits Y=1 instead of Y=0.
BTW: It's a regression as this worked until FF ~115? I just did not report it then, as i hoped it would be a temporary bug, as it's easy detectable.
|
||
Comment 4•2 years ago
|
||
Bob was asking which Firefox team could best address this problem; "Graphics" is the name of the team.
|
||
Updated•2 years ago
|
|
|
||
Comment 5•2 years ago
|
||
Hi, thanks for filing this, could you copy paste or attach to this bug the contents of your about:support page?
|
||
Comment 7•2 years ago
|
||
(In reply to support from comment #3)
BTW: It's a regression as this worked until FF ~115? I just did not report it then, as i hoped it would be a temporary bug, as it's easy detectable.
Can you use mozregression tool to find broken commit?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
Thanks.
|
|
||
Updated•2 years ago
|
The testtool does not work:
0:02.88 INFO: Using local file: $home/.mozilla/mozregression/persist/2023-01-16--mozilla-central--firefox-111.0a1.en-US.linux-x86_64.tar.bz2
0:02.88 INFO: Running mozilla-central build for 2023-01-16
0:10.27 INFO: Launching /tmp/tmp7rxpll13/firefox/firefox
0:10.27 INFO: Application command: /tmp/tmp7rxpll13/firefox/firefox -profile /tmp/tmpdxkzbpu5.mozrunner
0:10.27 INFO: application_buildid: 20230116211903
0:10.27 INFO: application_changeset: 23c1be504632a25d402332e7db55eb5699509d9f
0:10.27 INFO: application_name: Firefox
0:10.27 INFO: application_repository: https://hg.mozilla.org/mozilla-central
0:10.27 INFO: application_version: 111.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter):
0:10.59 WARNING: Process exited with code 11
retry
0:22.63 INFO: Running mozilla-central build for 2023-01-16
0:30.08 INFO: Launching /tmp/tmp5pl7d08_/firefox/firefox
0:30.08 INFO: Application command: /tmp/tmp5pl7d08_/firefox/firefox -profile /tmp/tmpx8py4mhi.mozrunner
0:30.08 INFO: application_buildid: 20230116211903
0:30.08 INFO: application_changeset: 23c1be504632a25d402332e7db55eb5699509d9f
0:30.08 INFO: application_name: Firefox
0:30.08 INFO: application_repository: https://hg.mozilla.org/mozilla-central
0:30.08 INFO: application_version: 111.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter):
0:30.40 WARNING: Process exited with code 11
exit
0:48.39 INFO: To resume, run:
It does not start the tested ff instance.
Even if it would, every tested FF would also need widevine plugin, h264 plugin etc. to work with NetFlix. It would help a lot if a copy of the regular profile would be made and used as all this is already there.
|
||
Comment 9•2 years ago
|
||
(In reply to support from comment #8)
Even if it would, every tested FF would also need widevine plugin, h264 plugin etc. to work with NetFlix. It would help a lot if a copy of the regular profile would be made and used as all this is already there.
The command-line option "--profile-persistence=clone-first" is useful in this situation. If you can get mozregression working at all, then on the first Firefox launch you can setup your profile completely, then quit Firefox and choose "retry" at the mozregression prompt. From that point on, you'll be using the profile you setup on the first run and all your changes will persist for the rest of the mozregression bisection.
|
||
Updated•2 years ago
|
|
|
||
Comment 10•2 years ago
|
||
Would you please try mozregression again with the "--profile-persistence=clone-first" argument?
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
|
||
Comment 11•2 years ago
|
||
I'm not able to reproduce this on Fedora 39 running Wayland on AMD Radeon. Netflix full-screens just fine.
|
|
||
Comment 12•2 years ago
|
||
|
||
Comment 13•2 years ago
|
||
Are you able to reproduce this if you disable one or the other display?
|
|
||
Comment 14•2 years ago
|
||
I'm not able to reproduce this on a dual-monitor configuration, either.
|
Reporter | |
Comment 15•2 years ago
|
||
So , after testing for a week now, i come to this result:
a) it's not a permanent issue, which will make it very hard to track down.
It's permanent on the boot it appears. rebooting helps to fix it.
b) I'm pretty sure, dual display is not relevant for it.
c) it happens in different recent versions, but: if it happens,it happens independend from the version. This may be a hint to track it down.
Otherwise i did not find anything out that may help.
|
|
||
Comment 16•2 years ago
|
||
Would it be possible to try on a different window manager than what you're running now with Cinnamon?
|
|
Reporter | |
Comment 17•2 years ago
|
||
i reseted cinnamon, i restarted the entire desktop session : no change
but i noticed something interesting:
The Netflix Mainwindow, where you select your movie is fullscreen too, but does not have the issue.
the actual streaming has that 1 pixel offset only.
Just for you, i will restart the desktop session with gnome and send another answere afterwards.
|
|
Reporter | |
Comment 18•2 years ago
|
||
after using ff with gnome, it took a while as gnome has a black theme as default, but after changing that to yellow, we got a hit:
it's independent from Desktop Environment
|
|
Reporter | |
Comment 19•2 years ago
|
||
Maybe we have something here: check the image i upload now.
use a gfx tool and zoom line 1 .. it's not yellow as it looked...it's transparent.
No idea why i could get the background captured in cinnamon, maybe because the panel is on the bottom, not on the top, but "transparent" could be a hint.
|
|
Reporter | |
Comment 20•2 years ago
|
||
|
|
Reporter | |
Comment 21•2 years ago
|
||
Info: the issues survives a reboot with a kernel change ( which means here: fresh compiled nvidia drivers )
:::::::: UPDATE ::::::::::
It's a SCALING ISSUE
Target display size: 1920x1080
source material in Netflix : 1280x720 => OK no background line .
source material in Netflix : 960x540 => not ok !!! 1 line on top with background
All source ratios are 16:9 , same as the destination ratio.
to match 1280 on 1920 the factor is 1.5
to match 960 on 1920 the factor is 2.0
I know it sounds crazy, but i think we have here a wired precision bug in the scalefactor calculation... if you multiply 540 * 1.999999999 you get 1079(int)/1079.999999946(float) pixel, instead of precisely 1080. From int perspective there is the exact 1 pixel we miss.
|
|
||
Comment 22•2 years ago
|
||
That sounds like a good lead. Does that sound possible Sotaro? I wonder if it's inside WR / layout / media if that is the case, will need some investigation to confirm if that is happening and where.
|
|
||
Comment 23•2 years ago
|
||
How did you set the fullscreen? Do you use PIP window and then make if fullscreen or dou you fullscreen it directly from Firefox?
Can you try to reproduce on any YT video? (Not netflix, I don't have it). You you see that if you play any clip from disk?
Thanks.
|
|
||
Comment 24•2 years ago
|
||
I tested 960x540 directly and I can't reproduce it (PIP or non-PIP mode).
|
|
Reporter | |
Comment 25•2 years ago
|
||
non-pip mode, directly inside ff.
Netflix uses "two masks" .. you choose your movie and than it it jumps to another page where it plays the video.
If FF is already in Fullscreen, the main window selecting the movie has no issues with that missing pixel line,
in play mode, it has no issues with 1280x720, but
in play mode with 960x540 it has an issue.
I my experience with 40 years of coding, i believe, it's a calculation result problem inside the javascript of netflix i.e. not using the correct rounding function to get rid of the float result and get absolut integer pixels.
The main question for ff devs here is:
Why does it result in a transparent line?
If ff is running fullscreen on 1920x1080, any media playback element should be inside a black rectangle of 1920x1080, resulting in black pixels where the media object isn't covering the pane/frame/whatever-you-call-it.
So, where does this transparency come from?
I do not have the js media api at hand to check if it's possible to call it with float variables for x & y , which would be surprising as there are no halve pixels on a real world display.
If x & y are integers, there will be structure to init the media playback and that will have a different resolution than the function call from js will provide ( 1920x1079 ) which will lead to a misaligned pixelbuffer as a result.
Regarding your experiment with directly open a video file with 960x540 that can't be compared here, as different functions are involved i.e. no javascript is needed to play a video if ff opens it as a file. I think js plays a major role here.
If i knew more about the media api i could debug the js code to a point where we get useful informations.
|
||
Updated•2 years ago
|
|
||
Comment 26•1 year ago
|
||
Reducing severity to S3 since this doesn't match the definition of "Major functionality/product severely impaired or a high impact issue and a satisfactory workaround does not exist".
|
|
Reporter | |
Comment 27•1 year ago
|
||
In this image the "ALPHA"ED Line is in mid screen. (Different bg image than on the other examples).
The question is still, why is that one line transparent and not black like the rest?
@Martin: YT is a very bad testsuite, as you never know which kind of scaling had to be done.
And of course, this could also be a bug in Netflixes JS code , but I'm pretty sure that the transparent line isn't on purpose ;)
|
|
Reporter | |
Comment 28•1 year ago
|
||
i informed Netflix about this bug..
Description
•