When XWayland support is enabled, Firefox first creates an XWayland surface, immediately closes this and then opens an XDG toplevel surface.
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
People
(Reporter: hjdskes, Assigned: stransky, NeedInfo)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0
Steps to reproduce:
I am the developer of Cage, a Wayland kiosk built on top of the wlroots library.
When I build my Wayland compositor with XWayland support disabled, Firefox Nightly (version 66.0a1) works perfectly fine. When I compile my compositor with XWayland support enabled, I run into a problematic situation.
Let me describe Cage's way of managing windows first, because it is essential to how I found the problem. Cage is a kiosk, meaning that it maximizes a single application window at a time and prevents the user from moving this around, minimizing it, et cetera. There is no panel or application menu. Thus, when the user closes the last application window, Cage also closes.
To summarize what I did exactly:
- Compile Cage with XWayland support enabled.
- Launch Cage with Firefox Nightly (i.e.,
GDK_BACKEND=wayland ./cage firefox-nightly
).
Actual results:
Now what happens with the above steps is that Firefox Nightly apparently creates an XWayland window first (but only when XWayland support is enabled, i.e., it works fine with XWayland support disabled) and almost immediately closes this again (the window does not get mapped).
However, Cage attempts to manage this XWayland window nonetheless. So when it then almost immediately closes, Cage closes as well because it has no further application windows open. When I add a workaround in Cage to not close when an unmapped XWayland window closes, Firefox Nightly starts up fine.
To summarize the problem:
Firefox Nightly spawns an XWayland surface on startup (when XWayland support is enabled in the compositor) only to almost immediately close this surface and launch an XDG shell surface instead.
Expected results:
What I expect to happen is that Firefox on Wayland does not spawn an XWayland surface that appears to be there for no reason. That is, I expect Firefox on Wayland to only launch with an XDG shell surface.
Here's the GitHub issue where I first discussed the problem: https://github.com/Hjdskes/cage/issues/18. It may contain more information.
Assignee | ||
Comment 2•5 years ago
|
||
Firefox Nightly apparently creates an XWayland window first
How is the XWayland window created? Which X11 call is used for it? Can you put breakpoint there and post stacktrace it it? It will identify which code creates that.
Thanks.
Can you put breakpoint there
Where would I put this breakpoint?
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 4•5 years ago
|
||
We're not going to fix this one.
Is there any difference with browser.startup.blankWindow = false
?
Comment 6•4 years ago
|
||
I got a backtrace in fedora 32 (idk if this is the only call to libX11, but is the first one)
#0 0x07f78115eab6f in poll () at /lib64/libc.so.6
#1 0x07f780f581b73 in _xcb_in_read_block () at /lib64/libxcb.so.1
#2 0x07f780f57f1b3 in xcb_connect_to_fd () at /lib64/libxcb.so.1
#3 0x07f780f58387b in xcb_connect_to_display_with_auth_info () at /lib64/libxcb.so.1
#4 0x07f780ff3206a in _XConnectXCB () at /lib64/libX11.so.6
#5 0x07f780ff226d9 in XOpenDisplay () at /lib64/libX11.so.6
#6 0x07f780b399dd2 in glxtest() () at /usr/src/debug/firefox-77.0.1/toolkit/xre/glxtest.cpp:373
#7 0x07f780b39a3b2 in fire_glxtest_process() () at /usr/src/debug/firefox-77.0.1/toolkit/xre/glxtest.cpp:560
#8 0x07f780b38e1dd in XREMain::XRE_mainInit(bool*) (this=0x7fff8c979d10, aExitFlag=0x7fff8c979ca0) at /usr/src/debug/firefox-77.0.1/toolkit/xre/nsAppRunner.cpp:3066
#9 0x07f780b3958db in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) (this=0x7fff8c979d10, argc=<optimized out>, argv=<optimized out>, aConfig=...)
at /usr/src/debug/firefox-77.0.1/toolkit/xre/nsAppRunner.cpp:4723
#10 0x07f780b395ed2 in XRE_main(int, char**, mozilla::BootstrapConfig const&) (argc=1, argv=0x7fff8c97b028, aConfig=...) at /usr/src/debug/firefox-77.0.1/toolkit/xre/nsAppRunner.cpp:4804
#11 0x0562127be449f in do_main(int, char**, char**) (argc=<optimized out>, argv=<optimized out>, envp=0x7fff8c97b038) at /usr/src/debug/firefox-77.0.1/objdir/dist/include/mozilla/UniquePtr.h:287
#12 0x0562127be3910 in main(int, char**, char**) (argc=<optimized out>, argv=<optimized out>, envp=0x7fff8c97b038) at /usr/src/debug/firefox-77.0.1/browser/app/nsBrowserApp.cpp:331
The NOTE on fire_glxtest_process()
says that glx is used on wayland because eglQueryRendererIntegerMESA
doesn't exist yet. I found this bug in mesa from :rmader who apparently is trying to remove the dependency in Bug 1640053, so I think this is blocked on (or is a dup of (?)) that bug.
Description
•