Wayland editor documentation popups appear on screen's edge and generate errors

[Cykyrios]

Tested versions

• Reproducible in v4.5.dev.custom_build [3b963ab]
• Not reproducible in v4.5-dev5

System information

Godot v4.5.dev (d9cd011) - Manjaro Linux #1 SMP PREEMPT_DYNAMIC Wed, 14 May 2025 14:56:34 +0000 on Wayland - Wayland display driver, Multi-window, 2 monitors - Vulkan (Forward+) - dedicated AMD Radeon RX 7900 XT (RADV NAVI31) - AMD Ryzen 9 7900X 12-Core Processor (24 threads) - 30.49 GiB memory

Issue description

Every time a class or function is hovered and its documentation popup appears, the popup is placed against the screen's right edge, and the following error is displayed in the output panel:

ERROR: platform/linuxbsd/wayland/display_server_wayland.cpp:1052 - Condition "p_window_id != MAIN_WINDOW_ID" is true. Returning: INVALID_SCREEN

This error points to this function.
In the following screenshot, I am hovering the rotated method:

Steps to reproduce

Open any script, hover a documented class or function (custom or built-in).

Note that disabling multi-window support (or enabling single window mode) causes the popup to appear at the correct location, but still generates the error.

Minimal reproduction project (MRP)

N/A

[akien-mga]

CC @Riteo

[ArchercatNEO]

Popup windows rely excessively on looking up what the screen which contains the window is. On Wayland as you'll have noticed this fails because we don't know which screen the window is mostly in so we just say nothing.

Besides, the popup code has a lot of duplicated code to get the "parent" rect, I will try to make a PR where reliance on screen is reduced enough to not have this by replacing a bunch of calls to window_get_current_screen to a helper method which hopefully behaves better

[deralmas]

It's probably related to window fitting, which should be checked with the new feature flag. I think I can take a look soon.

I'm sure that this is simply related to #104907. For consistency with other platforms it returns INVALID_SCREEN for anything but the main window. I don't know the details but IMO we should either always return a "valid" value or simply make sure that no code hard depends on the current screen.

Given that Wayland never had reliable way of detecting the current screen I'd argue that we should always return a fixed value and never error out, while making sure that all users of similar methods always have a fall-back where possible.

[deralmas]

Oh right. @bruvzg, since you made the PR in question, do you have some tips on what would be the best approach?

I think that it only showed the underlying issue. I clearly did not find all fitting attempts and disable them but I wonder if we could somehow bake a fall-back or something. You know the screen API best though so that's why I'm pinging you.