Closed Bug 1523889 Opened 5 years ago Closed 5 years ago

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)

66 Branch
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

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:

  1. Compile Cage with XWayland support enabled.
  2. 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.

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.

Flags: needinfo?(hjdskes)
Assignee: nobody → stransky
Blocks: wayland

Can you put breakpoint there

Where would I put this breakpoint?

Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Component: Untriaged → Widget: Gtk
Product: Firefox → Core

We're not going to fix this one.

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: needinfo?(hjdskes)
Resolution: --- → WONTFIX

Is there any difference with browser.startup.blankWindow = false?

Flags: needinfo?(hjdskes)

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.

You need to log in before you can comment on or make changes to this bug.