Skip to content

fix(wayland): decoration not clickable when initial visible is false - #1055

Closed
yuezk wants to merge 1 commit into
tauri-apps:devfrom
yuezk:fix_cannt_close_wayland
Closed

fix(wayland): decoration not clickable when initial visible is false#1055
yuezk wants to merge 1 commit into
tauri-apps:devfrom
yuezk:fix_cannt_close_wayland

Conversation

@yuezk

@yuezk yuezk commented Feb 9, 2025

Copy link
Copy Markdown

Problem

The decoration is not clickable if the window initial visible is false.

Reproduce

  1. Run the following code
  2. The close button, the maximum button, and the minimum button is not clickable.
use tao::{
  event::{Event, WindowEvent},
  event_loop::{ControlFlow, EventLoop},
  window::WindowBuilder,
};

#[allow(clippy::single_match)]
fn main() {
  env_logger::init();
  let event_loop = EventLoop::new();

  let window = WindowBuilder::new()
    .with_visible(false)
    .with_title("A fantastic window!")
    .build(&event_loop)
    .unwrap();

  window.set_visible(true);

  event_loop.run(move |event, _, control_flow| {
    *control_flow = ControlFlow::Wait;

    match event {
      Event::WindowEvent {
        event: WindowEvent::CloseRequested,
        ..
      } => *control_flow = ControlFlow::Exit,
      _ => (),
    }
  });
}

Solution

Avoid setting the above child property of the EventBox. The default value is false. Seems there is no need to set it to true.

https://docs.gtk.org/gtk3/method.EventBox.set_above_child.html

@github-actions

github-actions Bot commented Feb 9, 2025

Copy link
Copy Markdown
Contributor

Package Changes Through 6f278c7

There are 1 changes which include tao with minor

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package current next
tao 0.31.1 0.32.0

Add another change file through the GitHub UI by following this link.


Read about change files or the docs at github.com/jbolda/covector

@yuriyhanysh

Copy link
Copy Markdown

I can reproduce this bug on Fedora (KDE Plasma 6.5.5, Wayland) in cjpais/Handy app.
Can confirm the fix resolves the issue.

How can we merge it?

dgerhardt added a commit to dgerhardt/tao that referenced this pull request May 7, 2026
The default client side decoration handling of GTK is now used once
again. Custom CSD don't make any sense when no custom widgets are added
to the title bar. Futhermore, the custom CSD didn't work correctly and
introduced multiple bugs regarding the titlebar and server-side
rendering on Wayland.

This is mostly a revert of tauri-apps#979.

Fixes tauri-apps#1046, tauri-apps/tauri#13749, tauri-apps/tauri#14251,
tauri-apps/tauri#14748
Supersedes tauri-apps#1055
dgerhardt added a commit to dgerhardt/tao that referenced this pull request May 7, 2026
The default client side decoration handling of GTK is now used once
again. Custom CSD don't make any sense when no custom widgets are added
to the title bar. Futhermore, the custom CSD didn't work correctly and
introduced multiple bugs regarding the titlebar and server-side
rendering on Wayland.

This is mostly a revert of tauri-apps#979.

Fixes tauri-apps#1046, tauri-apps/tauri#13749, tauri-apps/tauri#14251,
tauri-apps/tauri#14748
Supersedes tauri-apps#1055
FabianLars added a commit that referenced this pull request Jun 29, 2026
…cessary (#1218)

* fix(wayland): remove broken custom CSD

The default client side decoration handling of GTK is now used once
again. Custom CSD don't make any sense when no custom widgets are added
to the title bar. Futhermore, the custom CSD didn't work correctly and
introduced multiple bugs regarding the titlebar and server-side
rendering on Wayland.

This is mostly a revert of #979.

Fixes #1046, tauri-apps/tauri#13749, tauri-apps/tauri#14251,
tauri-apps/tauri#14748
Supersedes #1055

* fix(wayland): propagate window events for CSD

This reverts #941, which broke CSD event handling on Wayland. A new fix
for #939 might now be needed.

Fixes tauri-apps/tauri#13440
Might fix (unconfirmed) tauri-apps/tauri#11856

* fix(wayland): ensure compositors don't force decorations

This enables CSD for undecorated windows to ensure that compositors with
server-side decoration support (e.g. KDE Plasma) do not apply them when
decorations are disabled for the window. Changing the decoration state
for existing windows is however still not supported.

This is a workaround for a GTK bug:
https://gitlab.gnome.org/GNOME/gtk/-/work_items/5479

Fixes #899, tauri-apps/tauri#6562

* chore: add changelog entry for Wayland CSD fixes

* fix(linux): reapply maximize fix from #979

This ensures that the window is resizable before maximizing it to avoid
unexpected behavior.

* Revert "fix(wayland): propagate window events for CSD"

This reverts commit 25edb8e.

* Reapply "fix(wayland): propagate window events for CSD"

This reverts commit 6b11c08.

* enable min/max buttons

* prevent crash on wsl/weston when maximizing undecorated window

* prevent duplicate mouse events

* keep default decorations

---------

Co-authored-by: Fabian-Lars <30730186+FabianLars@users.noreply.github.com>
@FabianLars

Copy link
Copy Markdown
Member

fixed in #1218

@FabianLars FabianLars closed this Jun 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants