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

Difficulty in Triggering Double-Click Events #2

Open
sdr0x07b6 opened this issue Dec 17, 2024 · 4 comments
Open

Difficulty in Triggering Double-Click Events #2

sdr0x07b6 opened this issue Dec 17, 2024 · 4 comments

Comments

@sdr0x07b6
Copy link

After integrating electron-drag-click, it seems that the functionality has returned to how it worked in Electron v22, allowing for both drag and click actions to coexist.

However, I have noticed that dblclick events often do not fire on elements with -webkit-app-region: drag; set. While click events perform better than dblclick events, they still occasionally fail to trigger.

I have conducted various investigations and believe that the logic within electron-drag-click is likely influencing this behavior. The insights derived from the AI's analysis of electron_drag_click.mm align with the issues I am experiencing:

  • dblclick events are difficult to trigger.
  • click events are better than dblclick events, but they still sometimes do not fire.

Is there anything I can do on my application's side to improve this situation?

Response from AI:

  1. Mouse Event Handling:
    The swizzledMouseEvent method initiates window dragging when the left mouse button is pressed. This behavior may interfere with the recognition of double-click events, making it difficult for the application to detect double-clicks correctly.

  2. Event Bubbling:
    If the swizzled method does not properly call the original event handling, double-click events may not bubble up correctly. This can particularly affect the recognition of double-clicks when handling NSEventTypeLeftMouseDown and NSEventTypeLeftMouseUp.

  3. Conflict Between Drag and Click:
    When drag operations and double-click operations compete, especially if the timing for double-clicks is short, the drag action may take precedence, preventing the double-click from being recognized.


@sdr0x07b6
Copy link
Author

Additionally, I can no longer drag and move a window that is not focused. My application allows users to drag the window from anywhere on the screen since it does not have a title bar. In Electron v22, even with acceptFirstMouse: false set during window creation, I was able to drag the window while it was unfocused.

However, since integrating electron-drag-click, I can only drag the window after it has been focused.

I need to keep acceptFirstMouse set to false for a specific reason. There are many UI elements, such as buttons and sliders, placed on the window. If acceptFirstMouse: true is set, and I happen to grab a UI element while trying to drag, it will trigger the UI action instead. With acceptFirstMouse: false, if I grab a UI element, it simply focuses the window without triggering any UI actions. Therefore, it is necessary to keep it set to false.

@sdr0x07b6
Copy link
Author

One more thing.
If I listen for mousedown events within the -webkit-app-region: drag; region, the left click fires only once, as expected, but the right click fires twice.

if ([theEvent type] == NSEventTypeLeftMouseDown && isDraggable.boolValue) {
  NSView* self = obj;
  [self.window performWindowDragWithEvent:theEvent];
}

In the case of a left click (NSEventTypeLeftMouseDown), performWindowDragWithEvent is called to initiate the window drag process. Since this process consumes the original event, the second call does not occur.

Since there is no code that takes right-click into account,

  1. the original event processing is executed
  2. further events are propagated, and
  3. The handler is called again

The result is that the handler is called twice.

@gerhardberger
Copy link
Owner

thank you for the thorough feedback @sdr0x07b6!

Good catch on the issue with the window drag not happening when the window was not focused. Came up with a fix for that and published it under version 1.0.6.

However the other two reports I have issue reproducing:

  • Double click not firing consistently feels to me the same in draggable and non-draggable areas. I don't see a difference.
  • Also based on my testing right clicks (contextmenu events) fire just once similarly to mousedown events.

Can you provide a reproducible example that I can try?

@sdr0x07b6
Copy link
Author

@gerhardberger Hello. First of all, I installed v1.0.6 and I can confirm that it works well regarding dragging unfocused windows.
Thanks for the great module you provide!

Please let me put on hold the issue of double clicks sometimes not emit. The reproducibility seems to be decreasing now. The reason is unknown. Until the other day it was reproducing frequently. Once it reproduced, it would never emit no matter how many times I repeated the double-click unless I moved the mouse coordinates.


Other problems were unexpected behavior related to mouseleave and mouseout.
However, I just found out that this is a problem with Electron itself, unrelated to electron-drag-click or -webkit-app-region: drag;.
I've issued an Issue.
electron/electron#45246


One more thing, when I run electronDragClick(), the wheel event is not fired in the -webkit-app-region: drag; region.

This also has the same minimal application and reproduction video as above.
https://github.com/sdr0x07b6/electron-mouse-events-wheel-test

The video may be difficult to understand as I am unable to video record me spinning the mouse wheel.


After my recent report, I had hacked a lot of mouse events, mainly in the renderer process, in order to implement the application according to its unexpected behavior.

However, I came to the conclusion that this was not enough, so I started to modify electron_drag_click.mm.
Since I could see some improvement, I intended to put it together properly before submitting a pull request to you.

However, as I worked on it, I noticed a few other issues that I thought were problematic in addition to the above.
I decided that fixing all of them might be tough with a partial modification approach to electron-drag-click. That is, the current code uses Objective-C via Node.js/N-API, but it seemed necessary to re-implement this in Swift as a pure macOS native plugin. Otherwise, it would be difficult to have fine control over clicks, for example.

But if I rewrote it in such a drastic way, it would no longer be electron-drag-click.
While I was confused about how far and how it should be modified, I got very busy and had to stop working on it...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants