Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
hakoptak opened this issue Mar 26, 2023 · 5 comments
Labels
platform: macOS status: needs triage This issue needs to triage, applied to new issues type: bug

Comments

@hakoptak
Copy link

hakoptak commented Mar 26, 2023

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:

Screen.Recording.2023-03-26.at.21.33.44.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 #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

@hakoptak hakoptak added status: needs triage This issue needs to triage, applied to new issues type: bug labels Mar 26, 2023
@github-project-automation github-project-automation bot moved this to 📬Proposal in Roadmap Sep 26, 2023
@doroved
Copy link

doroved commented May 17, 2024

@hakoptak I have encountered a similar problem
ahkohd/tauri-macos-menubar-app-example#54
My current version of Tauri = 1.6.2 and 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
Copy link

doroved commented May 20, 2024

@hakoptak If you are still facing this problem, try this solution and post whether it solved your problem or not? ahkohd/tauri-macos-menubar-app-example#54 (comment)

@doroved
Copy link

doroved commented May 25, 2024

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.

window.__TAURI_INTERNALS__.invoke('plugin:window|' + cmd)

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.

window.__TAURI_INTERNALS__.invoke(

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

@hakoptak
Copy link
Author

hakoptak commented Jun 1, 2024

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
Copy link

doroved commented Jun 1, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
platform: macOS status: needs triage This issue needs to triage, applied to new issues type: bug
Projects
Status: 📬Proposal
Development

No branches or pull requests

3 participants