#2296 Autocompletion not working on wayland

[Jan Dolinár]

Hello,

I have noticed, that the autocompletion in Scintilla is not working on wayland. The widget is not shown at all and no error is logged. It works when I force it to use XWayland (by setting environment variable GDK_BACKEND=x11), but that is just an ugly workaround.

This might or might not be related to [#2261], although for me it is broken even when there is secondary monitor plugged in.

Tested with SciTE (Version 5.1.5 Scintilla:5.1.4 Lexilla:5.1.3 compiled for GTK:3.24.30) and Geany (version 1.38 and current master) on Arch Linux with sway WM.

I'm willing to test and debug the potential solutions. However, I'm not very familiar with either GTK nor scintilla code, so I might need some hints. So far I believe the problem is probably somewhere in ListBoxX::Create implementation, but there is quite a lot going on. Any ideas where I could start poking?

[Jan Dolinár]

After bit more reconnaissance it seems that the problem is not actually in showing the window, but in its positioning and in my sway config.

I have the displays configured in sway config like this:

output HDMI-A-2 mode 1920x1080 pos 0 0
output eDP-1 mode 1920x1080 pos 0 1080

eDP-1 is internal display of my notebook, HDMI-A-2 is a HDMI port I use to plug in external monitor at work. I have the internal monitor offseted (to be below the external monitor). The code in ListBoxX::GetDesiredRect() does not detect that and returns screen-based coordinates, which are then probably incorrectly interpreted by GTK.

I might be able to fix this just by changing the config, but it doesn't solve the problem in #2261, which is definitely related. Actually, this is most probably a duplicate.

[Neil Hodgson]

Start in ScintillaBase::AutoCompleteStart, with the calls to SetPositionRelative most likely to be interesting. Add some tracing here fprintf(stderr, ... or, if more familiar with debuggers, break just before those calls to check what the rectangles are for placing the list.

[Jan Dolinár]

Thanks for the hint Neil, it proved very helpful. I tracked it down to a single condition in SetPositionRelative:

    if (sizey > rcMonitor.height || oy < rcMonitor.y) {
        oy = rcMonitor.y;

I believe that the oy value is correctly calculated in coordinates relative to the window (I gess the "o" stands for offset, rigt?), so comparing it to rcMonitor.y, which is in global coordinates is wrong. It triggers every time, since the offset is always within the 1080px high screen, which is less than the 1080px of monitor offset.

I believe that the correct thing to do here is to do the comparison in relative coordinates:

    if (sizey > rcMonitor.height || oy < 0) {
        oy = 0;

Similar fix would of course also be needed for all other conditions in this function, as they all seem to mix global and screen-relative coordinates.

The only remaining question is, whether this behaviour is specific to Sway (or Wayland). I really don't want to break it for other users using environments...

Also, I'm not sure how will this change affect various cases when the window is positioned over two monitors (although it is probably not very common case). I'll try to test it bit more on Monday, when I'll get to my office with the secondary monitor.

[Neil Hodgson]

I have been able to add a second virtual monitor but its very limited and breaks easily. The problem only occurs for me on Wayland, not Xorg.

The oy < rcMonitor.y clause comes from bug [#1920] change set [8e0cb3], "GTK: Fix popup positioning on monitors not positioned at 0,0".

The above change (with corresponding change for 'x') does appear to help show the list with Wayland on my system.

[Jan Dolinár]

I have tried to figure out whether the suggested change would affect X11 users (by running with GDK_BAKCEND=x11 on wayland, I don't have Xorg installed). Unfortunately, it seems it would break current behaviour on X11.

The problem is, that the behaviour of gdk_window_get_origin is not consistent accross platforms. I have looked through its implementation and found out it's probably documented behavior, see the comment here: https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gdk/wayland/gdkwindow-wayland.c#L3671-3705

So we should probably check what GDK backend is used. If it is wayland, than we can apply different corrections, while keeping current behaviour on X11 (and win32 and others which probably work correctly).

See the attached patch. Hope it is in correct format, I have never worked with mercurial before.

[Neil Hodgson]

That works OK on Wayland.

The Wayland headers and calls may not be available on other systems like Win32 so should be protected with #if defined(GDK_WINDOWING_WAYLAND) as is done in ScintillaGTK.cxx.

[Jan Dolinár]

Good point, I didn't think of that. Here is an updated patch.

[Neil Hodgson]

Fix committed as [77364f].

[Neil Hodgson]

Fix committed as [77364f].