[Bug]: Can not fire click(or double click) event if set a '-webkit-app-region: drag;' style

[kyle-go]

Preflight Checklist

• [X] I have read the Contributing Guidelines for this project.
• [X] I agree to follow the Code of Conduct that this project adheres to.
• [X] I have searched the issue tracker for a bug report that matches the one I want to file, without success.

Electron Version

23.2.1

What operating system are you using?

macOS

Operating System Version

13.3 (22E252)

What arch are you using?

x64

Last Known Working Electron version

22.0.3

Expected Behavior

I can drag the item to move window and fire click (double click) event.

Actual Behavior

click event NOT FIRED.

Testcase Gist URL

https://gist.github.com/fcc8358e36cae1dc3ed07458e4be46dc

Additional Information

Is it a bug?

[kyle-go]

Actually, as the window is a small tips window, I have to set the window property of :

    resizable: true,
    minimizable: false,
    maximizable: false,
    acceptFirstMouse: true,
    // movable: true,
    alwaysOnTop: true,
    fullscreenable: false,
    frame: false,

[jordancde]

Yep, all mouse events aren't being picked up when -webkit-app-region: drag;

[codebytere]

@nornagon can you confirm if this is newly intended behavior after the NonClientHitTest implementation change?

[kyle-w-20230331]

any update? thanks

[pacocoursey]

Seeing the same broken behavior, I'm guessing caused by #36230. It only applies to frameless windows (frame: false or titleBarStyle: 'hidden'). A workaround is to apply -webkit-app-region: no-drag to children that should receive pointer events.

Elements with -webkit-app-region: drag seem to act as z-index: Infinity, blocking all children from interaction and even becoming un-selectable via Chrome DevTools, which can make this really hard to debug!

The expected behavior is to follow CSS layering order, ignoring if -webkit-app-region is set.

[pacocoursey]

@codebytere Would you advocate for this to be prioritized? It's a pretty huge bug that makes any elements using -webkit-app-region completely unclickable and un-interactable, breaking UI across the majority of web apps that use Electron.

[gerhardberger]

Put up a fix for this issue here: https://github.com/electron/electron/pull/38208

[kyle-w-20230331]

any process？

[liees]

The mouse can trigger the pointer event normally, but my handle is completely useless. The magic is that I use git bash or vscode to start the development mode of electron and I can use the handle to click

It is invalid after using window shell or packaging...

so. what should I do

[ivanggq]

Hi, this issue seems a regression since around Electron v23 (not exactly sure) and is blocking issue for our product to migrate to a newer Electron. I appreciate your work on delivering a fix for it.

[kashamalasha]

On Windows behavior is the same. You can not handle mouse events without explicitly setting -webkit-app-region: drag in CSS on the element.

[kyle-w-20230331]

@codebytere any process? thanks

[foxt]

Noticed this regression when upgrading our app from v19 to latest.

@pacocoursey -- ideally, the expected behaviour is the old behaviour where any region of the page tagged with -war:d would become draggable

[jtvberg]

Sorry, not following. It looks like the bug was identified and a fix was found but the deployment of that fix was delayed and then closed out. What is the status of this bug? I still see the same issue in 26.4.0

[sdr0x07b6]

I have also been in trouble for a long time.

https://github.com/electron/electron/pull/38208 It seems to be showing that there are conflicts in the modified branch. If the inability to fix the conflicts is the cause of the neglect, I hope it will be reopened soon, as the conflicts are likely to grow even larger the longer they are neglected.

[jtbandes]

Hi there – wondering if there is any update to share on this issue? It seems like this bug makes it impossible to implement "double-click to maximize" behavior on linux (although for some reason, triple-click does work) if you want to be able to double-click a draggable region (which would be common for custom title bars).

[sdr0x07b6]

@jtbandes Hi, I wanted to know the current status too, so I asked them directly. https://github.com/electron/electron/pull/38208#issuecomment-1820432052 To be honest, I wasn't sure, but apparently some are of the opinion that this is not a bug. It seems that this is why progress is being hindered. In other words, the code has already been fixed, but the merging of the code seems to have been daringly stopped. As for me, I am convinced that it is a bug.

[kyle-go]

It's definitely a bug, it's not solved yet

[electron-issue-triage[bot]]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!

[sdr0x07b6]

bump

[KochiyaOcean]

I've noticed that in the Breaking changes document, it mentions that since Electron@23, the behavior of -webkit-app-region on macOS platform will matches that on Windows / Linux. Since this issue also happens since Electron@23, it looks like related this breaking change.

[sdr0x07b6]

This issue is not good with multiple threads..

Well, I have a new suggestion on this. https://github.com/electron/electron/pull/38208#issuecomment-2144092250

Simply claiming this issue is a bug will not save us from our pain. What do you guys think about accepting the new decision on the Electron side, but hoping that the new way of specifying our slightly unique UX-first requirements will be implemented as yet another intention? I think it would be more acceptable than simply continuing to call the specification change a bug.

I think there are better ideas than what I'm proposing. Let's all get our voices heard by Electorn.

[bpasero]

@codebytere this is an issue that bugs VS Code, where right-clicking into the custom title bar does not bring up the context menu to configure the title bar anymore since a long time. Is it possible to look at the provided PR to see if it fixes the issue?

[codebytere]

@bpasero the larger issue here is that it was never intended to work this way. It did work this way, essentially by accident, for several versions - some people came to rely on the functionality while it was briefly available, but switching it back would also break a lot of existing apps. That's why it remains stalled - we're still considering how to move forward or if it's the right choice to do so. Gerhard's PR restores the temporary functionality, but does so by doing what we also didn't want to do - going against the way draggable regions were intended to work in Chromium.

[bpasero]

@codebytere but there must be something Chrome is doing differently then because I have a draggable region at the empty space after tabs and it supports a context menu:

[codebytere]

@bpasero this is specific to frameless windows - a window with a custom titleBarOverlay is technically frameless. Chrome's window by comparison isn't frameless and wouldn't hit this.

[codebytere]

@bpasero would you mind opening a new issue for the contextmenu event bug?

[bpasero]

@codebytere https://github.com/electron/electron/issues/44386

Just to clarify: no other mouse event would work other than context-menu? Is there a reason? I now see we have code to detect a Cmd-click on macOS too.