https://bugs.kde.org/show_bug.cgi?id=483265
--- Comment #15 from Kacper Paczos <[email protected]> --- Created attachment 195843 --> https://bugs.kde.org/attachment.cgi?id=195843&action=edit window setup that triggers the findModal() recursion (GTK3/Wayland) — code before/after the app-side workaround I tracked my trigger down to the exact window setup, and it reproduces at will. The app is a small tool of mine (GTK 3.24.52 / PyGObject, Wayland session, no portal). It lives in the tray via AppIndicator, so there is no main window. The settings window is a Gtk.Dialog created with parent=None, and from it you can open an "Advanced" window: a plain Gtk.Window with set_transient_for(dialog). Closing it only does hide() (delete-event returns True), reopening does show_all() + present() on the same object. That's all it takes: opening that window kills kwin_wayland immediately, every time. I got two coredumps from it in one day, both with the same findModal() stack as in my earlier attachment. I haven't checked this on the GTK side, so treat it as a guess: I suspect that after the unmap GTK3 creates a new xdg_toplevel and sends set_parent again — if a stale transient link from the previous surface survives in KWin and the new one comes in, you get A->B->A, and findModal() has nothing to stop on. It might even be just present() re-linking the parent on the first show, because the crash also hit me fresh after the first launch of the GUI. I worked around it on my side — dropped set_transient_for and rebuilt the window on every open instead of hide/re-show, and the crash is gone (before/after code excerpt attached). But that's a workaround; a client shouldn't be able to take the compositor down with a weird window setup. Happy to put together a minimal reproducer if that would help. -- You are receiving this mail because: You are watching all bug changes.
