# Mutter bug report draft

## Where to file

File this in GNOME Mutter:

- https://gitlab.gnome.org/GNOME/mutter/-/work_items/new?type=Issue

This appears to be a Mutter issue because the observed behavior is window-management related on Wayland, not a behavior implemented by this project. This project only configures monitor layout through `gdctl` and does not move third-party windows between monitors in response to pointer focus changes.

## Suggested title

Window moved to lower monitor jumps back to primary upper monitor after clicking the primary monitor

## Report body

### Summary

On a dual-screen vertical layout under GNOME on Wayland, if I move a window to the lower monitor and then click on the upper primary monitor, the moved window is brought back to the upper monitor unexpectedly.

This looks like a Mutter/GNOME window-management issue. I initially suspected my monitor-layout helper, but after reviewing its code path, it only applies monitor topology through `gdctl` and does not contain any logic that moves arbitrary application windows in response to pointer clicks or focus changes.

### Environment

- Hardware: ASUS Zenbook Duo UX8406MA
- Monitors: two internal displays arranged vertically
- Layout: upper display is primary, lower display is positioned below it
- Session: GNOME on Wayland
- Distro: Ubuntu
- GNOME Shell version: `<fill in output of gnome-shell --version>`
- Mutter package version: `<fill in output of apt policy mutter mutter-common-bin | sed -n '1,12p'>`
- Kernel: `<fill in output of uname -r>`
- GPU: `<fill in output of lspci | grep -iE 'vga|3d|display'>`

### Steps to reproduce

1. Use a GNOME Wayland session with two displays in a vertical stack.
2. Set the upper display as the primary monitor.
3. Set the lower display below the primary monitor.
4. Open a normal application window.
5. Move that window to the lower monitor.
6. Click somewhere on the upper primary monitor.

### Actual result

The window that was moved to the lower monitor is brought back to the upper primary monitor.

### Expected result

Clicking the primary monitor should change focus only. It should not move a window from the lower monitor back to the primary monitor unless the user explicitly requested a move.

### Frequency

- `<always / often / intermittent>`

### Scope

- Affects Wayland-native apps: `<yes/no>`
- Affects Xwayland apps: `<yes/no>`
- Reproduces with GNOME extensions disabled: `<yes/no>`
- Reproduces after stopping local Zenbook helper services: `<yes/no>`

### Why I believe this belongs in Mutter

- The behavior is specifically about window placement after focus interaction across monitors.
- My local helper only applies monitor configuration via `gdctl set` when layout changes are requested or when hardware/lifecycle state changes.
- It does not contain code that repositions other apps' windows on pointer clicks.
- If the issue still reproduces after stopping local helper services, that further isolates it to GNOME/Mutter.

### Diagnostics

Please let me know if you want Mutter debug logs from a nested session, but here is the basic information I can provide immediately.

#### Display layout

```text
<paste output of: gdctl show>
```

#### GNOME and package versions

```text
gnome-shell --version
apt policy mutter mutter-common-bin gnome-shell
uname -a
```

#### GPU details

```text
lspci | grep -iE 'vga|3d|display'
```

#### Session details

```text
echo "$XDG_SESSION_TYPE"
echo "$XDG_CURRENT_DESKTOP"
loginctl show-session "$XDG_SESSION_ID" -p Type -p Desktop -p Name
```

#### Check whether helper services are involved

```text
systemctl --user stop zenbook-duo-session-agent.service
sudo systemctl stop zenbook-duo-rust-daemon.service zenbook-duo-rust-lifecycle.service
```

Then retry the reproduction and note whether the issue still happens.

#### Journal logs around the reproduction

```text
journalctl --user -b --no-pager | grep -iE 'gnome-shell|mutter|zenbook'
journalctl -b --no-pager | grep -iE 'gnome-shell|mutter|zenbook'
```

### Additional notes

- The lower monitor is layout-wise below the primary monitor, not to the side.
- The key symptom is not just focus transfer; the window is actually re-homed to the primary monitor.
- If needed, I can test whether this depends on maximized state, tiled state, or whether the app is Wayland-native vs Xwayland.

## Suggested duplicate search terms

Before filing, search Mutter issues for:

- `window jumps back to primary monitor`
- `window moved to second monitor returns to primary`
- `wayland vertical monitor layout focus moves window`
- `Zenbook Duo monitor click moves window`

## Local evidence from the Zenbook Duo project

Relevant code paths reviewed:

- [ui-tauri-react/src-tauri/src/runtime/session_agent.rs](ui-tauri-react/src-tauri/src/runtime/session_agent.rs) only applies GNOME display layout through `gdctl`, including `--below` placement for the second internal display.
- [ui-tauri-react/src-tauri/src/runtime/daemon.rs](ui-tauri-react/src-tauri/src/runtime/daemon.rs) only triggers display replays on lifecycle, lid, session registration, or hardware policy changes.
- [ui-tauri-react/src-tauri/src/lib.rs](ui-tauri-react/src-tauri/src/lib.rs) only focuses the Zenbook Duo app window itself from tray or single-instance flows.

These paths do not implement generic cross-monitor window moves for arbitrary applications.