https://bugs.documentfoundation.org/show_bug.cgi?id=174207

            Bug ID: 174207
           Summary: Missing parent window
           Product: LibreOffice
           Version: 26.8.1.1 release
          Hardware: All
                OS: Linux (All)
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: Calc
          Assignee: [email protected]
          Reporter: [email protected]

Description:
I hit this bug in my work but used AI to help solve it.  Do with this what you
will.

Text Import (CSV) dialog sets xdg_toplevel.set_parent(nil) under native
Wayland, so tiling window managers treat it as a standalone window instead of a
dialog

Steps to Reproduce:
1. Run LibreOffice natively under a Wayland compositor whose window manager
doesn't float every new top-level window by default (e.g. Hyprland, a tiling
WM).
2. Open or import a .csv file in Calc so the Text Import wizard dialog appears.
3. Capture the Wayland protocol traffic for the dialog's surface, e.g.
WAYLAND_DEBUG=1 soffice --calc file.csv.

Actual Results:
The dialog's xdg_toplevel explicitly declares no parent:
-> xdg_wm_base#34.get_xdg_surface(new id xdg_surface#48, wl_surface#47)
-> xdg_surface#48.get_toplevel(new id xdg_toplevel#49)
-> xdg_toplevel#49.set_parent(nil)
-> xdg_toplevel#49.set_app_id("soffice")
With no parent set, the dialog is indistinguishable at the protocol level from
an ordinary top-level application window. A tiling WM without app-specific
heuristics tiles it like any other window instead of recognizing it as a modal
dialog. In my case (Hyprland), this caused the app's own splash screen — a
separate, correctly-floating window — to render on top of the tiled dialog and
intercept all mouse clicks meant for it (keyboard Tab/Enter still worked, since
the dialog held input focus).

Expected Results:
A modal wizard dialog spawned from an open document should set its xdg_toplevel
parent to the owning document window via xdg_toplevel.set_parent(), per the
xdg-shell protocol, so Wayland compositors can treat it correctly (float it,
stack it above its parent, etc.) without needing per-application window-manager
rules.


Reproducible: Always


User Profile Reset: No

Additional Info:
Worked around locally with a Hyprland window rule that force-floats this dialog
by matching its title — a per-user compositor-side mitigation, not a fix for
the missing parent relationship.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to