[bug] Window changes position when AlwaysOnTop and AcceptFirstMouse window combined with Normal window

hakoptak commented 1 year ago

Describe the bug

Hello,

My app has two windows, one is alwaysOnTop and has acceptFirstMouse, the other is a normal window. The problem (see recording below) occurs when the normal window is clicked and then the on top window. When the op top window is clicked its window suddenly shifts position:

https://user-images.githubusercontent.com/26923796/227799984-5b74572e-8066-4ed0-8b27-043ec4a796f4.mov

In the recording I try to explain that the offset of the shifted window is exactly the mouse position + top left window offset.

This bug may be related to https://github.com/tauri-apps/tauri/issues/4056.

Reproduction

See recording. Below you find the window properties:

    "windows": [
      {
        "label": "whiteboard",
        "acceptFirstMouse": false,
        "alwaysOnTop": false,
        "decorations": false,
        "fileDropEnabled": false,
        "focus": false,
        "fullscreen": false,
        "maximized": true,
        "transparent": true,
        "resizable": false,
        "visible": true,
        "x": 0,
        "y": 0,
        "url": "https://localhost/whiteboard"
      },
      {
        "label": "asteriks",
        "acceptFirstMouse": true,
        "alwaysOnTop": true,
        "center": true,
        "decorations": false,
        "fileDropEnabled": false,
        "focus": true,
        "fullscreen": false,
        "transparent": true,
        "resizable": false,
        "visible": false,
        "height": 96,
        "width": 96,
        "url": "https://localhost/asteriks"
      }
    ],
    "macOSPrivateApi": true

Expected behavior

The always on top window should not shift in position.

Platform and versions

Environment
  › OS: Mac OS 12.6.3 X64
  › Node.js: 19.6.0
  › npm: 9.4.0
  › pnpm: Not installed!
  › yarn: Not installed!
  › rustup: 1.25.2
  › rustc: 1.68.1
  › cargo: 1.68.1
  › Rust toolchain: stable-aarch64-apple-darwin 

Packages
  › @tauri-apps/cli [NPM]: 1.2.3
  › @tauri-apps/api [NPM]: 1.2.0
  › tauri [RUST]: 1.2.3,
  › tauri-build [RUST]: 2.0.0-alpha.2,
  › tao [RUST]: 0.15.8,
  › wry [RUST]: 0.23.4,

App
  › build-type: bundle
  › CSP: unset
  › distDir: https://localhost/
  › devPath: https://localhost/

App directory structure
  ├─ target
  ├─ node_modules
  ├─ icons
  └─ src

Stack trace

Additional context

No response

doroved commented 5 months ago

@hakoptak I have encountered a similar problem https://github.com/ahkohd/tauri-macos-menubar-app-example/issues/54 My current version of Tauri = 1.6.2and I don't see a similar problem with a regular window (NSWindow). Has the current problem persisted for you in the latest stable version of Tauri?

I would like to point out that this problem only occurs when clicking on the data-tauri-drag-region area

doroved commented 5 months ago

@hakoptak If you are still facing this problem, try this solution and post whether it solved your problem or not? https://github.com/ahkohd/tauri-macos-menubar-app-example/issues/54#issuecomment-2121013207

doroved commented 5 months ago

The gist of the problem: When you first click on a data-tauri-drag-region in an inactive window with .always_on_top and .acceptFirstMouse, sometimes there is a conflict between acceptFirstMouse and start_dragging events and the window shifts.

Demo: https://youtu.be/McfLrebxq7I?t=20

This is my final solution that solves the problem perfectly:

<script setup lang="ts">
import { appWindow } from "@tauri-apps/api/window";

const fixDragging = (event: MouseEvent) => {
  if (
    event.currentTarget === event.target &&
    // and was left mouse button
    event.button === 0 &&
    // and was normal click or double click
    (event.detail === 1 || event.detail === 2)
  ) {
    event.preventDefault();
    setTimeout(() => appWindow.startDragging(), 100);
  }
};
</script>

<template>
  <div class="title-bar" @mousedown="fixDragging"></div>
</template>

Note that the minimum delay should be exactly 100ms, because if you set for example 50ms, it will not work.

@FabianLars I don't want to create a new issue, ping you to notice how quick and easy it is to close this problem. https://github.com/tauri-apps/tauri/blob/0c61784efbec4ae5e9d1c89460dcb3380e46b65e/core/tauri/src/window/scripts/drag.js#L42

setTimeout(() => window.__TAURI_INTERNALS__.invoke('plugin:window|' + cmd), 100);

I think it also makes sense to add a delay to maximize the window, as perhaps double-clicking could also cause a problem. https://github.com/tauri-apps/tauri/blob/0c61784efbec4ae5e9d1c89460dcb3380e46b65e/core/tauri/src/window/scripts/drag.js#L60

setTimeout(() => window.__TAURI_INTERNALS__.invoke('plugin:window|internal_toggle_maximize'), 100);

hakoptak commented 5 months ago

Hi @doroved, thanks for addressing the issue.

I have disabled the AcceptFirstMouse feature and never looked back. If I have time I will try to enable it to see if this is fixed. If so I will close this issue.

doroved commented 5 months ago

Hi @doroved, thanks for addressing the issue.

I have disabled the AcceptFirstMouse feature and never looked back. If I have time I will try to enable it to see if this is fixed. If so I will close this issue.

I doubt it's fixed, since you had this problem on version 2+beta and I had it on 1.6.7 Do not hurry to close the problem, enable AcceptFirstMouse and if the problem does not appear immediately, then use the program for a few days, because the bug at least with me randomly pops out. + for the sake of interest try my solution, at the moment I have never caught the bug.

tauri-apps / tauri