#54427: fix: honor win.setEnabled(false) and modal parents under Wayland
Description of Change
On Linux, win.setEnabled(false) and showing a modal: true child only blocked input to the window under X11. Under Wayland the window kept receiving clicks and keys and win.isEnabled() always returned true, because the implementation installed an X11-only event rewriter behind an IsX11() check.
This switches to DesktopWindowTreeHostLinux::DisableEventListening(), which Chromium uses to make a window inert behind its own modal dialogs and which behaves the same on X11 and Wayland, and deletes the rewriter. The "disabling parent windows" specs now run on the Wayland lane too.
Tested under Xvfb and weston 13 with synthetic pointer and keyboard input, and on Ubuntu 24.04 GNOME (Mutter, Wayland session): a disabled window and a modal's parent drop clicks and keys and get them back when re-enabled or when the child closes, on both backends.
Checklist
- I have built and tested this change
- I have filled out the PR description
- I have reviewed and verified the changes
- tests are changed or added
Release Notes
Notes: Fixed win.setEnabled(false) and modal child windows not blocking input on Wayland.
Backports
Semver Impact
Semantic Versioning helps users understand the impact of updates:
- Major (X.y.z): Breaking changes that may require code modifications
- Minor (x.Y.z): New features that maintain backward compatibility
- Patch (x.y.Z): Bug fixes that don't change the API
- None: Changes that don't affect using facing parts of Electron