1869724 - [GNOME/Wayland] Fullscreen video is cut to upper left quarter

Status: RESOLVED MOVED

(Core :: Widget: Gtk, defect, P3)

Description

[urtsi.santsi]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:120.0) Gecko/20100101 Firefox/120.0

Steps to reproduce:

1. Have a 200% display scale in Gnome Shell (wayland)
2. Play any video on one of the youtube, vimeo, imgur, vbox7 - probably can be reproduced with any video website. The video must be played on the site - the same video embedded in other sites work.
3. Enter browser fullscreen with F11
4. Enter video fullscreen

Actual results:

Only upper left quarter of the video is visible. Player buttons that are not in the upper left quarter are also not visible.

Expected results:

The entire video should be visible.

Comment 1

[urtsi.santsi]

This is a Fedora 39 system with Radeon™ 780M Graphics. Reproducible on new user and new profile without any add-ons. Chrome and native players work correctly. See also https://github.com/webcompat/web-bugs/issues/130684

Comment 2

[Darkspirit]

Does this problem also occur with https://nightly.mozilla.org?

Comment 3

[urtsi.santsi]

Yes, it is still present with nightly - 122.0a1 (2023-12-13) (64-bit).
I've seen some bug reports that are similar - like 1767019 - but they were all related to screensharing.

Comment 4

[Martin Stránský [:stransky] (ni? me)]

Can you create a screencast of the issue?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Collect_information_for_a_bug_report

Do you use fractional scale? Do you see 100%, 125%, 150%... scales on display settings?

Comment 5

[urtsi.santsi]

Attachment: Screencast from 2023-12-15 12-32-09.webm

This is just a random video from blendernation.com - https://www.blendernation.com/2023/12/14/boolean-holes-to-quad-topology/ and the same video on youtube.com - https://www.youtube.com/watch?v=vEOdZVBMSyQ&t=9s

In the screencast you can see the video on youtube:

• In the first half the browser is not in fullscreen and the video can enter fullscreen and work as expected
• In the second half the browser is in fullscreen and when the video enters fullscreen only the upper left quarter is visible

The exact same scenario works in both cases when the video is embedded, in this case in blendernation. This is already listed in the bug description.

I'm using 200% - this is also listed in the bug description.

I'll attache the additional info described on https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Collect_information_for_a_bug_report shortly.

Comment 6

[urtsi.santsi]

Attachment: about:support.txt

Comment 7

[urtsi.santsi]

Attachment: gfxlog.txt

Comment 8

[urtsi.santsi]

firefox-120.0.1-1.fc39.x86_64

Comment 9

[urtsi.santsi]

There is no vainfo installed and dnf can't find it.

Comment 10

[Martin Stránský [:stransky] (ni? me)]

Thanks, I can reproduce it too. The crucial step here is Firefox Fullscreen (F11) and then video fullscreen.

Comment 11

[Martin Stránský [:stransky] (ni? me)]

Wayland only, X11 works okay.

Comment 13

[Kestrel]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=3072155b3ba7258eeffe3cc96f1065c8b8eb3e4f&tochange=3b5a0c666d81128f40fa48e3e30c16c64e64b959

Regressed by Bug 1824552.

Comment 14

[Martin Stránský [:stransky] (ni? me)]

Kestrel, thanks for the regression window. Emilio, any idea here?
Thanks.

Comment 15

[Dmitry Gutov]

Coming from Bug 1872943, perhaps I should add that my about:support reports Display0 as "7680x4320@60Hz scales:2.000000|2.000000".

Whereas my actual screen's resolution is 3840x2160. It doesn't seem like a good idea to render anything at 7680x4320 (and then downscale?), if that indeed happens. And looking at the about:support output attached to this report, this problem seems to be there for urtsi.santsi as well (albeit with 5120x3200).

When fractional scaling is enabled, Display0 is correctly reported to be "3840x2160@60Hz scales:2.000000|2.000000".

Comment 16

[Emilio Cobos Álvarez (:emilio)]

As I understand it, either Mutter is reporting a wrong logical pixel size without fractional scaling (scale-monitor-framebuffer) enabled, or GTK is not interpreting it well. Then firefox thinks that the screen size is much larger and well.

This happens on other GTK applications too. Without fractional scaling, if I open gtk4-demo, and go to the inspector, I see in the "Global > Monitor > Geometry" section:

• 3840 × 2160 @ 2 at 0, 0

Whereas if I enable it I see:

• 1920 × 1080 @ 2 at 0, 0

Which is the expected output.

It seems, with fractional scaling disabled, either the scale should be 1, or the output should be the same as with fractional scaling enabled.

As a consequence, in Firefox, the web-exposed screen.width / screen.height interfaces are twice as much as they should.

Robert, it seems like this comes from the xdg-output's logical size prop. Do you think that:

• This is a bug in Mutter that needs fixing, or.
• GTK needs to listen to both wl-output and xdg-output to determine which size / position scaling to use somehow?

If the latter I'm happy to give a poke at fixing gtk. Thanks.

Comment 17

[Emilio Cobos Álvarez (:emilio)]

I gave a shot at fixing this (or working around the Mutter bug if it is one) in https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6722 for GTK4 and https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6723 for GTK3.

Comment 18

[urtsi.santsi]

If this is the root cause why is there a difference in behavior when Firefox is fullscreen (incorrect) and when it is not (correct)?
And how is this handled in Totem and Chrome - do they use different API or a workaround?

Comment 19

[Dmitry Gutov]

This might be relevant: https://gitlab.gnome.org/GNOME/mutter/-/issues/2631

See jadahl's explanations in the comments. And https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/195 which resulted from it.

Comment 20

[Emilio Cobos Álvarez (:emilio)]

(In reply to urtsi.santsi from comment #18)

If this is the root cause why is there a difference in behavior when Firefox is fullscreen (incorrect) and when it is not (correct)?

Because we resize the content to the (wrong, in this configuration) screen size eagerly here, see bug 1177155.

If we're not fullscreen already, when the window becomes fullscreen we reflow the browser UI, and it happens to "fix" the size. But if we're already fullscreen then we remain with the wrong size.

And how is this handled in Totem and Chrome - do they use different API or a workaround?

Chromium seems blurry here with the failing configuration, but yeah they might not be hitting the issue, which happens to be about how Firefox uses the screen size during fullscreen transitions, see above.

They do hit this bug tho, in Chromium screen.width is 3840 and screen.height is 2160 rather than the expected value.

Comment 21

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1824552

Comment 22

[Robert Mader [:rmader]]

Sorry for replying late! Yeah, so with https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6832 landed I hope https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6723 will so, too - it looks like a good solution for now.

Comment 23

[nicolas m]

Hi! I have had the same issue from one day to another since late summer (I think), using Nightly.

It was working well before that.

The issue happens not just on Wayland, but also on Xorg.

Also note that for a couple of days in January, it actually worked again, and I thought it was solved.

Now back to having the video cropped and double the size.

Comment 24

[nicolas m]

(In reply to nicolas m from comment #23)

The issue happens not just on Wayland, but also on Xorg.

Sorry, seems to work on Xorg now. I had tried a few months ago to see if it could solve the issue and it didn’t at that time.

Comment 25

[Emilio Cobos Álvarez (:emilio)]

Seems like those GTK-side fixes were merged so things should start working there.

Comment 27

[Martin Stránský [:stransky] (ni? me)]

It's still broken on gtk3-3.24.41-1.fc40.x86_64 - I wonder which version is supposed to have the fix.

Comment 28

[Martin Stránský [:stransky] (ni? me)]

Updated to gtk3-3.24.42 and it fixed now.