XWayland: Menu windows resized full screen and crash?
-
Hello,
I would like to ask a question about the following behaviour.
In various Gtk/Xwayland apps ( in Chormium for UT, Signal UT, Min Browser, Rocket.Chat) when a secondary X window is opened (like menu window or overlay window), and I see it gets immediatly resized full screen (which is not normal). Then it bothers it and it closes immediately. This is kind of problematic.
My questions is:
1- Is there a lomiri deamon that resize automatically new XWayland windows to fullscreen
2- Is it possible to disable this behaviour, or at least for certain windows?
3- I see that in uWolf the problem does not happen how come? @fuseteam any idea?Here are the X logs for example when I open the menu of the Min browser:
bin/xev -root CreateNotify event, serial 18, synthetic NO, window 0x3ef, parent 0x3ef, window 0x800013, (-53,66), width 829, height 1433 border_width 0, override YES MapNotify event, serial 18, synthetic NO, window 0x3ef, event 0x3ef, window 0x800013, override YES ConfigureNotify event, serial 18, synthetic NO, window 0x3ef, event 0x3ef, window 0x800013, (125,302), width 829, height 1433, border_width 0, above 0xe00003, override YES ClientMessage event, serial 18, synthetic YES, window 0x800013, message_type 0x111 (_NET_ACTIVE_WINDOW), format 32 PropertyNotify event, serial 19, synthetic NO, window 0x3ef, atom 0x111 (_NET_ACTIVE_WINDOW), time 635893, state PropertyNewValue FocusOut event, serial 19, synthetic NO, window 0x3ef, mode NotifyNormal, detail NotifyPointer FocusOut event, serial 19, synthetic NO, window 0x3ef, mode NotifyNormal, detail NotifyPointerRoot FocusIn event, serial 19, synthetic NO, window 0x3ef, mode NotifyNormal, detail NotifyDetailNone KeymapNotify event, serial 19, synthetic NO, window 0x0, keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ConfigureNotify event, serial 19, synthetic NO, window 0x3ef, event 0x3ef, window 0x800004, (0,0), width 1080, height 2277, border_width 0, above 0x800013, override NO PropertyNotify event, serial 19, synthetic NO, window 0x3ef, atom 0x111 (_NET_ACTIVE_WINDOW), time 635897, state PropertyNewValue ConfigureNotify event, serial 19, synthetic NO, window 0x3ef, event 0x3ef, window 0x800013, (125,302), width 829, height 1433, border_width 0, above 0x800004, override YES ConfigureNotify event, serial 19, synthetic NO, window 0x3ef, event 0x3ef, window 0x800013, (125,302), width 1080, height 2277, border_width 0, above 0x800004, override YES UnmapNotify event, serial 19, synthetic NO, window 0x3ef, event 0x3ef, window 0x800013, from_configure NO UnmapNotify event, serial 19, synthetic YES, window 0x3ef, event 0x3ef, window 0x800013, from_configure NO DestroyNotify event, serial 19, synthetic NO, window 0x3ef, event 0x3ef, window 0x800013 PropertyNotify event, serial 19, synthetic NO, window 0x3ef, atom 0x111 (_NET_ACTIVE_WINDOW), time 635961, state PropertyNewValue FocusOut event, serial 19, synthetic NO, window 0x3ef, mode NotifyNormal, detail NotifyDetailNone FocusIn event, serial 19, synthetic NO, window 0x3ef, mode NotifyNormal, detail NotifyNonlinearVirtual KeymapNotify event, serial 19, synthetic NO, window 0x0, keys: 157 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0(We see that we have a fullscreen resize here: ConfigureNotify event, serial 19, synthetic NO, window 0x3ef,
event 0x3ef, window 0x800013, (125,302), width 1080, height 2277,
border_width 0, above 0x800004, override YES ) -
Anyone? Any info about that would of tremendous use for all Wayland/gtk apps ( Chromium UT, Min browser, Signal UT, Rocket.Chat )
-
are you sure that the messages you see are coming from the menu ? What I tried is to redirect the output of xev to a file that I examined by tailing it from ssh. When the menu opened and did its particular dance, I saw nothing on my screen.
From my understanding, the window created when opening a menu is not rooted, so it's not seen when using xev -root (err, warning here, I am decidedly no X window expert
)Apart of that, I have no idea on the uWolf mystery and it's indeed baffling. The only far fetched hypothesis that I can think is that this difference is not coming from the packaging but from the underlying code base (ie, Firefox vs Chrome) is not using Gtk in the same way.
-
@gpatel-fr said in XWayland: Menu windows resized full screen and crash?:
are you sure that the messages you see are coming from the menu ? What I tried is to redirect the output of xev to a file that I examined by tailing it from ssh. When the menu opened and did its particular dance, I saw nothing on my screen.
From my understanding, the window created when opening a menu is not rooted, so it's not seen when using xev -root (err, warning here, I am decidedly no X window expert )Yes I'm sure that the window corresponding to the menu appears in xev, and in xdotools for a second. are you sure you have the exported the correct DISPLAY ? Everything seems to show that the window is instantaneously resized which is not normal for a menu window.
the window created when opening a menu is not rooted
What do you mean not rooted?
Apart of that, I have no idea on the uWolf mystery and it's indeed baffling. The only far fetched hypothesis that I can think is that this difference is not coming from the packaging but from the underlying code base (ie, Firefox vs Chrome) is not using Gtk in the same way.
Or that they have found a workaround to make it work? @chromiumos-guy @fuseteam ?
-
@pparent said in XWayland: Menu windows resized full screen and crash?:
you sure you have the exported the correct DISPLAY ?
I said that I saw nothing when the menu opened. Before that, when the program itself initialized, I saw lots of messages so I think I captured the output correctly.
@pparent said in XWayland: Menu windows resized full screen and crash?:
What do you mean not rooted?
it's a top level window.
@pparent said in XWayland: Menu windows resized full screen and crash?:
they have found a workaround to make it work?
I have quickly browsed the issues, git log, did not find anything interesting but I may have missed it of course.
-
This is very strange, just tu make sure I explain the process:
1- I start The Min Browser.
2- I open an adb shell session and I do the following:
phablet@ubuntu-phablet:~$ if [ "$DISPLAY" = "" ]; then i=0 while [ -e "/tmp/.X11-unix/X$i" ] ; do i=$(( i + 1 )) done i=$(( i - 1 )) display=":$i" export DISPLAY=$display fi cd /opt/click.ubuntu.com/min.pparent/current export LD_LIBRARY_PATH=lib/aarch64-linux-gnu/ bin/xev -root3- I try to open the top left hand corner menu, and exactly at that time I see the following log appear in the shell
CreateNotify event, serial 18, synthetic NO, window 0x3ef, parent 0x3ef, window 0x600013, (-53,66), width 1189, height 1433 border_width 0, override YES MapNotify event, serial 18, synthetic NO, window 0x3ef, event 0x3ef, window 0x600013, override YES ConfigureNotify event, serial 18, synthetic NO, window 0x3ef, event 0x3ef, window 0x600013, (-54,302), width 1189, height 1433, border_width 0, above 0x800003, override YES PropertyNotify event, serial 18, synthetic NO, window 0x3ef, atom 0x111 (_NET_ACTIVE_WINDOW), time 9737872, state PropertyNewValue FocusOut event, serial 18, synthetic NO, window 0x3ef, mode NotifyNormal, detail NotifyNonlinearVirtual FocusIn event, serial 18, synthetic NO, window 0x3ef, mode NotifyNormal, detail NotifyDetailNone KeymapNotify event, serial 18, synthetic NO, window 0x0, keys: 130 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ConfigureNotify event, serial 18, synthetic NO, window 0x3ef, event 0x3ef, window 0x600004, (0,0), width 1080, height 2277, border_width 0, above 0x600013, override NO PropertyNotify event, serial 18, synthetic NO, window 0x3ef, atom 0x111 (_NET_ACTIVE_WINDOW), time 9737873, state PropertyNewValue ConfigureNotify event, serial 18, synthetic NO, window 0x3ef, event 0x3ef, window 0x600013, (-54,302), width 1189, height 1433, border_width 0, above 0x600004, override YES ConfigureNotify event, serial 19, synthetic NO, window 0x3ef, event 0x3ef, window 0x600013, (-54,302), width 1080, height 2277, border_width 0, above 0x600004, override YES UnmapNotify event, serial 19, synthetic NO, window 0x3ef, event 0x3ef, window 0x600013, from_configure NO UnmapNotify event, serial 19, synthetic YES, window 0x3ef, event 0x3ef, window 0x600013, from_configure NO DestroyNotify event, serial 19, synthetic NO, window 0x3ef, event 0x3ef, window 0x600013 PropertyNotify event, serial 19, synthetic NO, window 0x3ef, atom 0x111 (_NET_ACTIVE_WINDOW), time 9737927, state PropertyNewValue FocusOut event, serial 19, synthetic NO, window 0x3ef, mode NotifyNormal, detail NotifyDetailNone FocusIn event, serial 19, synthetic NO, window 0x3ef, mode NotifyNormal, detail NotifyNonlinearVirtual KeymapNotify event, serial 19, synthetic NO, window 0x0, keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -
and here is what I do:
in the UT terminal, start xev -root >/home/phablet/mytrace.txt
connected via ssh, I do
tail -f mytrace.txt
then I open the application, and look at my computer screen when I open the menu. That's at this point that I see nothing. When the app is opening (and closing) I see tons of messages.
-
Yes but did you try to reproduce with the method I posted above?
I can't reproduce yours because xev is not installed by default in the system. I guess you have installed it.
-
I did not install it, I have installed min and it's available here
-
Well if I run the xev from the Min browser in the terminal from the phone screen, somehow it gets killed while I navigate in the Min Browser. So I indeed cannot see the same log, but the cause seems to be totally different, simply that xev is not running anymore.
Anyway it seems better to me to run xev directly from adb/ssh as I showed before.
-
@pparent said in XWayland: Menu windows resized full screen and crash?:
xev is not running anymore.
I don't see that. I'll try your method this week-end. What's interesting is that I see the same window number (0x3ef) in the initial trace, when the program starts (before attempting to open a menu) so my suspicion is that it is the main app window..
-
I did not try your method yet, however I debugged the problem in my method. It's something (I guess Lomiri itself) that is sending a signal when the window is paused while switching. It is killing xev. The fix is to use TweakUT to keep the terminal awake, then my method works whatever the launch mode (direct > or with starting a new task &>)
So I could repro the problem you have seen. No discrepancy here.
I have looked a bit at Firefox and Chrome under vanilla Linux (Kubuntu 24.04) and xev reports something very different than under UT. That is, no strange events, basically the system reports the menu being created and mapped and that's all.
I have also 'packaged' a recent version of Firefox freshly downloaded from the editor's site, that is, I did
env GDK_DPI_SCALE=2 MOZ_ENABLE_WAYLAND=0 DISABLE_WAYLAND=1 ./firefox
and the menus in the top bar display (if no scaling were done, I'd guess that the menu would display if by a stroke of luck I could hit the minuscule screen area)
So my guess is that's not a clever packaging trick, that's something that Firefox is doing differently than Chrome. I searched for a Chrome Linux arm64 build but it seems that Google has insufficient resources to generate arm64 Linux builds (it's not a joke, it's exactly what is said by a Google employee in the Chrome issue tracker).
I'd say that as under UT Chrome and Firefox are hitting XWayland that is hitting Mir, the problem could be all the way down to Mir. The version of Mir in current 24.04 UT is woefully outdated. When it will be updated, the way forward will be to switch to Wayland anyway and drop XWayland.
-
From my current understanding, there is some special code in the xWayland server inside UT, that automatically resize the windows to the size of the screen. In the case of a menu window, this obviously create problems.
I guess there must be exceptions for certain types of windows, or when the window has certain properties. For exemple I see the the gtk filedialogs windows in gtk do not get resized fullscreen.
It is possible that the menu windows in uWolf have different property that prevent the system from resizing them.
I will investigate that, I guess if i find a property that prevent the system from resizing the windows, I could add it to the window very fast with a script, and prevent the system from interfering.
-
did you notice that there are menus that are displaying fine in the ChromiumUT app ? the menus in the top bar are not working, but the Google application menu is working correctly (although there is a wobble the first time, maybe it's the automatic resizing you are referring to, but it's failing to stop it to work)
