Fallback gtk file picker window size automatically set to an extremely large value

[matchatealeaf]

System Information

• niri version: 25.02

• Distro: Artix Linux 6.13.5-artix1-1

• GPU: AMD RX 6600

• CPU: AMD Ryzen 5 5600X

I've encountered an issue where the y value of xdg-desktop-portal-gtk file picker window size is set to an extremely large value of a few hundred thousand pixels.

This caused programs that uses the fallback gtk file picker to crash whenever the file picker is invoked.

Here's an example error message from these programs:

[Parent 32501, Main Thread] WARNING: Native Windows taller than 65535 pixels are not supported: 'glib warning', file /var/tmp/build/firefox-64d9c39553ae/toolkit/xre/nsSigHandlers.cpp:187

(Mullvad Browser:32501): Gdk-WARNING **: 22:46:46.578: Native Windows taller than 65535 pixels are not supported
[Parent 32501, Main Thread] WARNING: ../gtk/gdk/wayland/gdkdisplay-wayland.c:1446: Unable to create Cairo image surface: invalid value (typically too big) for the size of the input (surface, pattern, etc.): 'glib warning', file /var/tmp/build/firefox-64d9c39553ae/toolkit/xre/nsSigHandlers.cpp:187

(Mullvad Browser:32501): Gdk-CRITICAL **: 22:46:46.596: ../gtk/gdk/wayland/gdkdisplay-wayland.c:1446: Unable to create Cairo image surface: invalid value (typically too big) for the size of the input (surface, pattern, etc.)
Exiting due to channel error.
Exiting due to channel error.
zsh: segmentation fault  mullvad-browser

This is solved easily by resetting the window size with gsettings reset org.gtk.Settings.FileChooser window-size.

However, it is weird that this happened suddenly after using niri for a couple of months.
I certainly do not have hundred thousands of monitor resolution to caused the file picker window size to be set to those values manually.

Some extra infos:

• Output config: output "HDMI-A-2" { mode "1920x1080"; }
• Monitor resolution: 1920x1080
• Single HDMI monitor.

[YaLTeR]

The dialog remembers its size; niri will in most cases just ask it to come up with a size itself. I'm not sure how you got it to remember such a tall size. Could it be that you did a set-window-height with a large % by accident? Either way, I don't see a niri bug here.

[matchatealeaf]

I did not set the window height manually anywhere.
I've only resize the window via mouse dragging which shouldn't cause it to be such a tall size since I don't have that much screen space anyway.

I would agree that this doesn't seem like a niri bug, but I can't think of any other thing that would resize windows except for niri.

I'm just wondering if there's some edge case where niri's calculation for resizing of windows (e.g., changing to floating, moving to another workspace, drag and drop, tiling or stacking etc.) hit a singularity or division by a small value and caused the height to blow up to a large value.

[YaLTeR]

Well unless you find such a case with a reproducer, this bug is not actionable. We don't even know if it exists.

[matchatealeaf]

Thanks for the help, I will close this as this seems to be the root cause: mullvad/mullvad-browser#418