Conflict: acceptFirstMouse + data-tauri-drag-region

[doroved]

In my application, I use the ability to pin a window and I ran into a problem, the cause of which I searched for many hours)

Make these edits to the code to reproduce the problem.

1. src/App.tsx - Add an area for dragging the window

   <h1>Menubar App</h1>
   <div style={{ background: "red", padding: "20px", cursor: "grab" }} data-tauri-drag-region> DRAG ME </div>

2. Comment out the line
   

   tauri-macos-menubar-app-example/src-tauri/src/fns.rs

   Line 53 in dff4941

   panel.order_out(None);

3. tauri.conf.json - Add acceptFirstMouse and startDragging

  "tauri": {
    "allowlist": {
      "all": false,
      "window": {
        "startDragging": true
      },
...
    "windows": [
      {
...
        "acceptFirstMouse": true

After starting the application, open the application by clicking on the system tray icon, you can drag the window anywhere, then you have to click in the area outside the window, wait a few seconds, then click in the data-tauri-drag-region.
It is still unclear what exactly triggers the problem, but you will notice that when you click on the data-tauri-drag-region again, the window position will change dramatically.
https://youtu.be/McfLrebxq7I

And if you drag the window to the upper right corner and do the operation described above, the window will disappear altogether, apparently changing its position outside the visibility of the macbook window.
https://youtu.be/vof60XG6Dm4

When using a regular window, without tauri-nspanel with the settings always_on_top(true) and accept_first_mouse(true) I do not see such a problem.

I hope you will be able to solve this problem and maybe better implement it in tauri-nspanel package.

[doroved]

@ahkohd Hi, any thoughts on what the problem might be :)

[doroved]

Perhaps we need to write our own data-tauri-drag-region handler that won't conflict with NSPanel?

[doroved]

Apparently there is a conflict between acceptFirstMouse and always_on_top (in case of NSPanel instead of always_on_top we just don't hide the panel when changing focus) due to the fact that while clicking on data-tauri-drag-region 2 events acceptFirstMouse and start_dragging are triggered simultaneously and that's why sometimes we get a bug with window/panel position change.
I seem to have solved the problem by adding a 100ms delay for start_dragging.

By the way, here tauri-apps/tauri#6568 there is a problem with NSWindow in Tauri 2.0.0-alpha.2, although I have everything ok in 1.6.2, only with NSPanel (by the way you should check .always_on_top for NSPanel).

Here is the solution to the problem. At the moment it seems that everything is ok, I will click, test further)

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

const fixDragging = () => {
  setTimeout(() => {
    appWindow.startDragging();
  }, 100);
};
</script>

<template>
  <div
    class="flex h-screen items-center justify-center text-slate-300"
    @mousedown="fixDragging"
  >
</template>

If further tests show that the problem is fixed, then Tauri developers should add 100ms delay in this code.
https://github.com/tauri-apps/tauri/blob/0c61784efbec4ae5e9d1c89460dcb3380e46b65e/core/tauri/src/window/scripts/drag.js#L42

[ahkohd]

@doroved, I'm glad you found a workaround to this issue!

[doroved]

@doroved, I'm glad you found a workaround to this issue!

I think we can close this issue, I described the problem and solution here:
tauri-apps/tauri#6568 (comment)

I don't know if it makes sense to do something for nspanel, it's probably better to wait for the edit to be made on the Tauri side, and if someone encounters this problem now, they can use my solution.

[ahkohd]

@doroved, I'm glad you found a workaround to this issue!

I think we can close this issue, I described the problem and solution here: tauri-apps/tauri#6568 (comment)

I don't know if it makes sense to do something for nspanel, it's probably better to wait for the edit to be made on the Tauri side, and if someone encounters this problem now, they can use my solution.

Okay, I'll pin the issue. Thanks!