Repository: tauri
Issue: [bug] Dragging window causes focus toggling, plus eats mouse event(s)
Labels: type: bug,platform: Windows,status: needs triage

### Describe the bug

On Windows, clicking any draggable region within a Tauri window causes a toggling of window focus and the loss of certain mouse events as observed by the webview. This occurs both with parts of the window which are within the native frame (e.g. titlebar, resize borders), and designated drag regions within the webview. When clicking in a webview drag region, the loss of the mouse up event very rarely seems to cause the window to get stuck in a dragging state, such that it will follow the mouse until the user clicks again.

While draggable regions are associated with this behaviour, actually dragging them is unnecessary. Only clicking is required, though in certain cases you may need to hold the click for a moment before releasing.

A [prior issue](https://github.com/tauri-apps/tauri/issues/5864) describes what I believe to be the same problem. I've opened a new issue to provide additional information and up-to-date reproductions steps, since this actually bit me when developing my current project.

When clicking on a drag region within the webview, the following events are observed by the webview in this order:
- When clicking without prior focus:
  - Focus gained
  - Mouse down
  - Focus lost
  - Focus gained

- When clicking with prior focus:
  - Mouse down
  - Focus lost
  - Focus gained

Notice the absence of a mouse up event: this will seemingly never be observed by event listeners in the webview. (If you double-click instead of single clicking, then the second mouse up event _will_ be visible: but this is only because it triggers the window maximize handler instead of the drag start handler.)

When clicking in the native window frame area, outside the webview, the observed events are similar, with the addition of a delay:
- When clicking without prior focus:
  - Focus gained
  - (delay)
  - Focus lost
  - Focus gained

- When clicking with prior focus:
  - (delay)
  - Focus lost
  - Focus gained

(No mouse events are seen by the webview in this case, but this is expected, since they occur in the frame area beyond the webview's bounds.)

About the delay:
- The delay is not present when clicking on a webview drag region. It only appears when clicking on the native window frame.
- When clicking on the native window frame, the focus toggle seems to occur after a small delay of around half a second, at least on my system.
- If the window has prior focus and the click is released faster than that, the focus toggle may not be observed at all, though it will always appear if the click is held for a time before releasing.
- For whatever reason, without prior focus, this effect seems _not_ to be sensitive to how long the mouse is held down. Clicking, even quickly, will cause focus/unfocus/focus.
- When I accidentally introduced a great deal of lag by using the webview dev tools and Window Detective to observe window messages at the same time, this bug disappeared, both when interacting with the native window frame and within drag regions within the webview. Extra focus/unfocus events were not observed, nor were mouse up events eaten. I suspect that enough lag was introduced in just the right places that the misbehaving code's ordering was changed, causing it to no longer manifest the bug.

I'm not certain the delay will replicate on every system, but the gap is suspiciously close to 500ms.

Here's a recording of a trace of the window messages, captured using Window Detective. Starting without focus on the window, I mouse over the native titlebar, pause, click down, hold for a moment, and then release. While the mouse button is held down, the mouse is not moved at all.

![Tauri focus issue - window messages](https://github.com/user-attachments/assets/a5ddde44-3a2f-4e8a-9356-a7fa68fe8d2b)

Here also is a static screenshot of those window messages after the fact, with coloured bars drawn along the left-hand side so that you can easily associate them with the cause:

![screenshot  2024-08-24 20-32-27 (annotated)](https://github.com/user-attachments/assets/e1d7926d-16c2-4caf-a976-7ee9782194c5)

- Green indicates messages that were sent after clicking down with the left mouse button.
- Orange indicates messages also sent while the left mouse button is held down, but which only triggered after a ~500ms delay (note the timestamps), and which appear to correlate with the focus toggle issue I describe above.
- Blue indicates messages that were sent after releasing the left mouse button.

I poked through the Tauri internals a bit to see if I could figure out exactly where this was happening, but I'm still getting familiar with the project and with Rust, so I'm not very effective yet. I hope the above information can help someone else with a better grasp of the project pinpoint where it's happening.

Do let me know if there's anything further information I could provide that would be useful.

### Reproduction

1. Create a minimal Tauri program using `create-tauri-app`:
    ```
    cargo create-tauri-app --rc
    ```

2. Add `core:window:allow-start-dragging` to the program permissions.

3. Insert the following code at the end of `main.js`:
    ```js
    // Misc. setup. Can be ignored.
    let dragRegion = document.createElement('div');
    dragRegion.style.height = '100%';
    dragRegion.style.width = '100%';
    dragRegion.style.position = 'fixed';
    dragRegion.style.top = '0';
    dragRegion.style.left = '0';
    dragRegion.style.display = 'flex';
    dragRegion.style.justifyContent = 'center';
    dragRegion.style.alignItems = 'center';
    dragRegion.style.backgroundColor = 'grey';
    document.body.append(dragRegion);
    
    let label = document.createElement('div');
    label.textContent = 'Drag anywhere in the grey region to move the window.';
    label.style.pointerEvents = 'none';
    dragRegion.append(label);
    
    // Make document draggable via its interior
    // Requires core:window:allow-start-dragging
    dragRegion.setAttribute('data-tauri-drag-region', '');
    
    // Make change of focus observable
    window.addEventListener('focus', () => console.log('Focus gained'));
    window.addEventListener('blur', () => console.log('Focus lost'));
    
    // Make mouse events observable
    //
    // We use capturing listeners so that we see the event before Tauri calls both
    // preventDefault() and stopPropagation() on it (see: drag.js).
    document.addEventListener('mousedown', () => console.log('> Mouse down'), { capture: true });
    document.addEventListener('mouseup', () => console.log('> Mouse up'), { capture: true });
    ```

4. Run the program in dev mode:
    ```
    cargo tauri dev
    ```

5. Open the dev tools and watch the messages logged in the console as the window is clicked.


### Expected behavior

The window should not lose focus when it is clicked while already focused. Mouse up events within the webview should not be silently ignored, even when clicking on a drag region.

### Full `tauri info` output

```text
[✔] Environment
    - OS: Windows 10.0.19045 X64
    ✔ WebView2: 127.0.2651.105
    ✔ MSVC: Visual Studio Community 2022
    ✔ rustc: 1.80.0 (051478957 2024-07-21)
    ✔ cargo: 1.80.0 (376290515 2024-07-16)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (environment override by RUSTUP_TOOLCHAIN)
    - node: 18.12.1
    - npm: 8.19.2

[-] Packages
    - tauri [RUST]: 2.0.0-rc.6
    - tauri-build [RUST]: 2.0.0-rc.6
    - wry [RUST]: 0.42.0
    - tao [RUST]: 0.29.1
    - tauri-cli [RUST]: 2.0.0-rc.3
    - @tauri-apps/api : not installed!
    - @tauri-apps/cli [NPM]: 2.0.0-rc.3

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../src
```


### Stack trace

_No response_

### Additional context

_No response_