Electron: Support click-through of transparency

Created on 31 Mar 2015  ·  77Comments  ·  Source: electron/electron

As commented here, https://github.com/atom/atom-shell/pull/949#issuecomment-87087841 - transparent windows unfortunately are of limited use unless you can click through the transparent area.

I noticed that in the documentation it is stated that this is blocked by an upstream bug. The nw.js project DOES have support for this, but i'm not sure how different their implementation is...

I think this is worth the issue to track discussion and implementation, so here it is.

componentransparent enhancement

Most helpful comment

Some people in this thread already proposed adding click-through based on transparency using the GPU, but would that really be useful? Most windows need a shadow to make window hierarchy clear. I've been working on an always-on-top floating widget/helper tool which really needs the shadows to stand out. Since these have an alpha>0, click through would be impossible. After working some more on the library posted above, I found out that most of the language features already exist to support native click-through.

Would it be possible to implement the way this library works natively?

JS/CSS equivalent

body {pointer-events: none}
window.addEventListener('mousemove', event =>
  if (event.target === document.documentElement) // <html>-element
    setIgnoreMouseEvents(true, {forward: true)   // {forward: true} keeps generating MouseEvents
  else
    setIgnoreMouseEvents(false)
)

The pointer-events CSS rule is standardized and prevents elements from being the event.target. You may add something like {transparent: true, clickThrough: 'pointer-events'} to the BrowserWindow options to activate this feature.

There's more to it when actually implementing it and supporting drag-events etc, but it doesn't seem to cause anything near a bottleneck. MouseEvents are generated anyhow, so performance shouldn't really be impacted. The ignoreMouseEvents state can be cached so only mouseenter/mouseleave triggers native window code.

animated png <a href="recorded@60fps">recorded@60fps</a>, <a href="played@60fps">played@60fps</a>

Edit: This piece of code would actually be enough if setIgnoreMouseEvents worked properly cross-platform. Currently it's a combination of workarounds including polling the mouse at screen refresh rate instead of listening for events in certain circumstances.

All 77 comments

While nw.js does support it, it comes with some pretty hefty drawbacks. First of all it requires disabling GPU acceleration, and secondly it only works on OS X and Windows (based on their documentation).

+1, this one's plaguing Slack too, since we display all of our notifications in a transparent window.

+1, this is critical for the project I'm working on.

+1, this would be excellent.

Interested in hearing the latest on this. For my purposes, I'd love if we could set a transparent window to have _no_ click area. So you could have an always-on-top full screen overlay that didn't catch clicks.

I'm interested too, i'm building an app with a semi transparent window that's on top of other applications but mouseevents need to get through to the other applications.

+1

Any news about it?

the linked chromium bug is marked wont-fix
https://code.google.com/p/chromium/issues/detail?id=387234

the last comment is:

11 [email protected]

You know, just btw, people in Atom team can do it by themselves if their users need it, right?

so nothing is currently going to happen until someone on the atom team decides to do it or persuades the chrome team it is worth putting on their backlog (and they said it was low priority).

Just ran into this today, It has put a -massive- issues into my plans of using a new window has an overlay. (in fact, it is now impossible)

I would love a fix for this!

Is there any work in progress for this? Will there be a chance for the Electron team to make this possible without being added to Chromium?

+1

Assuming this won't be resolved through the Chromium code, is there a plausible way to have the application listen for a click event and then trigger the proper counterpart in GTK or similar?

i use ahkscript

#c::
    WinSet, ExStyle, ^0x20, A
    WinSet, Transparent, 255, A
    return

press Win+C on active window, and its click-through now

@zcbenz Any update on this? 😄

To people watching this issue: if you simply want to make the whole window click-though, you can use the new win.setIgnoreMouseEvents API introduced in v1.2.2.

Also on making specified regions transparent, I have come up with some ideas on the implementation (but do not assume it would be done in near future):

For Linux, it is actually very easy by using the XShapeCombineRectangles API, the implementation of SetIgnoreMouseEvents is just setting only a region of (0, 0, 1, 1) to accept mouse events.

For Windows, it is easy to set the shape of window, but there is no API to control which regions can accept mouse events.

For OS X, either setting window shape or setting click-though regions is impossible if you don't have control to the rendering code.

And since Chromium does complex hardware acceleration, it becomes super hard to implement custom click-through regions. NW.js does it by disabling hardware acceleration, and patching the rendering code, this is an approach that I definitely don't want to take.

My idea for the implementation on OS X/Windows is, we just make the whole window click-through, and then create a transparent window as child window, and use it to capture all mouse events. Since we have full control of the child window, we can set it to the shape of the regions that users do not want to be click-though, and then send all mouse and keyboard events received in the child window to the parent window.

In this way we don't have to patch Chromium, so it is easy to maintain and hardware acceleration works. The downside is we have to very carefully redirect mouse and keyboard events, to make the window behave as if it there is no child window.

If, like me, your use case for this feature is fairly simple this gist might be of interest. It is a basic implementation of what @zcbenz is describing, creating one clickable area which redirects mouse events to the parent.

During the development of my Windows gadget project which requires click-thru, I have unintentionally come up with a somewhat fancy but practical solution which works to define a clickcable area of truly arbitrary shape.

In the renderer process, use "screen.getCursorScreenPoint()" to keep tracking the cursor position, and then send the coordinates to the main process regularly. On the main process, use "webContents.capturePage()" to capture the image of that exact 1x1 pixel on the renderer window. Since it's just 1 pixel, the performance cost is ignorable, and then you can define whether that pixel is clickable or not by looking at the opacity value. This way, you can practically define a truly pixel-correct clickable area. The only issue left here is a function to detect the mousedown state regardless of the cursor position.

Electron click through transparency example
https://gist.github.com/StickyCube/ed79421bc53cba38f5b74b060d3f15fa

@ButzYung Could you please tell me that how can I get opacity value from NativeImage (webContents.capturePage() return NativeImage)? Thanks.

@varavut Capturing a 1x1 image as an example, it would be something like this.

```
webContents.capturePage({x:0,y:0,width:1,height:1}, function(image) {
var buffer = image.getBitmap()

// send the data back to renderer for processing, with buffer[3] being the alpha channel
webContents.send('capturePage', 'RESULT|' + [buffer[0],buffer[1],buffer[2],buffer[3]])

});
```

@ButzYung Thanks for your solution. I tried it, the key is the interval of tracking. 100ms for my computer, looks well. If I used webContents.capturePage, CPU cost high. I would define the area which is click-through, just check the point if in the area.

@cecilpeng In my case I give a 200ms delay after the current webContents.capturePage has finished, instead of doing another capture immediately. That's roughly 4-5 captures/second, enough for the purpose of checking transparency, and the CPU usage is ignorable.

@ButzYung yes, it is better to do another capture after last has finished. I'm still worried about the timeout solution, it's not smart enough. We can't know what happens on the users' computer. I recommend that javascript is a good languague to observe instead of inspect.

I'm very much a HTML noob but is it not possible to simply:

  1. setup a 'onMouseLeave' event on HTML elements which you want to be clickable.
    --> this mouse leave event executes win.setIgnoreEvents(true)
  2. setup a 'onMouseEnter' event on HTML elements which you want to be clickable.
    --> this mouse enter event executes win.setIgnoreEvents(false)

Due to my lack of HTML knowledge there may be an issue with this in certain scenarios... But in my head it seems to be the, currently, ideal workaround. Except for the extra setup time required of course?

@sancarn The problem with your approach is that when .setIgnoreMouseEvents is set to true in step 1, there is no more mouse event and thus the usual HTML-driven "onMouseOver" event in step 2 will not fire anymore.

But hey, now that I think about it, if your approach is combined with my "capturePage" approach, which can detect mouseover on/off by comparing opacity without the usual HTML events, it may produce interesting results. I have actually tried, and guess what, it works lol. Now, you can have a truly pixel-correct clickable area.

Lol riiight. Hilarious that I didn't see that as a flaw xD

Indeed merging the two approaches is also slightly less heavy which is nice.

When it comes to getting the pixel, I haven't tested this but on Windows it may be easier to use hookWindowMessages() with message WM_MOUSEMOVE = 512.

When I set transparent=true I cannot double click to maximize the window. (more problems see here) The only reason I need to set transparency is create a rounded corner window. If this issue is resolved, we can definitively resolve many issues and save many efforts. Really looking forward for someone to implement this.

Hi, I just wanted to +1 this bug because it would be a really nice addition for my use case. This would really make a difference in our UX. A huge one.

_Sent from my Google Pixel XL using FastHub_

If you're on Windows with a similar use case to mine you may find my recently accepted PR useful. It adds a parameter to setIgnoreMouseEvents that makes the window click-through as usual, but still allows you to listen DOM events such as mouseleave. Provided that you can determine when the window should be click-through based on mouse movements you should be able to opt out and return to normal as in this example. For a bit more context, my use case was that I wanted a hole in the web page (possibly covered by other elements). The example shows how I enabled/disabled click-through as I entered/left an element. The transparency itself was made using a backdrop filter via experimental CSS features.

Unfortunately I don't know Linux or Mac GUI programming so I'm unaware whether a similar approach is possible there. Still, I figured that I'll inform of it in case somebody finds it useful.

@andens that sounds great really! Please someone implement the same for Linux and Mac! That would be good enough for me!

_Sent from my Google Pixel XL using FastHub_

@andens i seem to be having a weird issue with it, in order to get it working correctly i need to pass forward on both false and true, else it won't work. After doing that, i need to reload the the webcontent at least once. After all this, seems to be working flawlessly :)
(Using v1.8.0)

Doesn't work (follows example)

      divThing.addEventListener('mouseleave', () => {
        win.setIgnoreMouseEvents(true, {forward: true});
      });


      divThing.addEventListener('mouseenter', () => {
        win.setIgnoreMouseEvents(false);
      });

Works after reloading at least once

      divThing.addEventListener('mouseleave', () => {
        win.setIgnoreMouseEvents(true, {forward: true});
      });

      divThing.addEventListener('mouseenter', () => {
        win.setIgnoreMouseEvents(false, {forward: true});
      });

Weird nasty temp fix on core.js

@edunad Sorry for the delay; I'm swamped with other stuff at the moment. If I remember correctly, forward should make no difference whatsoever when the first parameter is false, but I may be mistaken. The code you posted forwards when leaving the div and stops when entering, whereas the documentation example does it the other way around. Is this intended? Even so, the semantics should be the same, just that the forwarding area is essentially inverted, but perhaps there are some corner cases in how Chromium behaves.

One quick thing I can think of is that you probably don't get the leave event (and thus begin forwarding) until you have first entered the div. Have you considered this? Hopefully I can find some time to try it out.

@andens No problem! Take all the time you need, i'm in no hurry. (ended up revering back to 1.7 + using disableHardwareAcc() )

What i needed was the opposite of the example (ignore inputs if not hovering the div).
I did try the example and i had the same issue :(

Basically it's a small div on each the sides of the screen,

I've added console logs to it, and it seems mouseenter / mouseleave would get triggered, but once mouseleave was triggered i coulnd't re-trigger the mouseenter to disable ignoreMouse.

Would be nice to use hardware acceleration and click electron elements if they are not completely invisible (opacity 0)

+1, this is critical for the project I'm working on.

A great solution that works flawlessly for me is the answer by @ButzYung, rather than checking opacity, I simply check if the mouse is within my button container div, if it's inside I enable mouse events, if it's outside I disable them and the window becomes click through again.

Do we have any Linux / Mac programmers who could try and implement the same
thing that the PR Andreas is mentioning does in Windows? I would really
really love to see that working <3

On Thu, Feb 22, 2018 at 2:59 PM AlexCatch notifications@github.com wrote:

A great solution that works flawlessly for me is the answer by @ButzYung
https://github.com/butzyung, rather than checking opacity, I simply
check if the mouse is within my button container div, if it's inside I
enable mouse events, if it's outside I disable them and the window becomes
click through again.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/electron/electron/issues/1335#issuecomment-367688459,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIc892p83oXBrGkNdlwSrLTJVtDgZjOaks5tXXKvgaJpZM4D3dRY
.

Does anyone have a workaround for mac for this? Or know why setIgnoreMouseEvents(true, {forward: true}) is not available for mac?

I am thinking of using osx-mouse and checking if the mouse global mouse position if over the html element to re-enable mouse events.

window.setIgnoreMouseEvents(true) actually works on macOS.

@paulius005 It's only implemented on Windows because it uses the native WinAPI. This kind of functionality is highly dependent on OS features and (I would guess that) it's probably very difficult to realize unless the OS provides explicit support.

What you suggest sound very similar to what is done for Windows. If you know low-level macOS programming, feel free to study https://github.com/electron/electron/pull/10183 for inspiration and I'll assist with the ideas the best I can.

Any news about this feature? I'm trying to use setIgnoreMouseEvents on Windows 10 app without success. I'm also using the app with transparent option enabled.

@leidsongermano i'm currently using v1.8.7 with app.disableHardwareAcceleration();, seems to work fine. The only downside is disabling the hardware acceleration. With this you won't need to setIgnoreMouseEvents

@edunad i was testing with the electron-quickstart which uses electron 0.36.*. After that i updated to the latest versionp (2.0.2) and it works pretty fine now. Thanks!

@edunad that worked for me. disableHardwareAcceleration slowed my app down too much on Mac though but for some reason was fine on Windows. So ended up disableHardwareAcceleration just for Windows machines

My app https://github.com/singuerinc/overlay is useless without click on transparency so I stop the development until this is fixed.

I used to build this app with Flash/AIR without any problem, I don't see why it's not possible to implement this in Electron.

@edunad @adeperio Does disableHardwareAcceleration allows us to ignore mouse events on both Mac/Windows on transparency, but still click on "solid" html elements?

@singuerinc yes, if you enable disableHardwareAcceleration and set the app transparency to true, only solid and if you set the opacity to 0.1 will be clickable. Do take note about the slowdown on macs (check @adeperio's response)

@edunad I just tried a bunch of different ways, but it doesn't work.
I set up a empty-transparent-fullsize window without any element and I'm not able to click-through, I have no idea what I'm doing wrong.
window.setIgnoreMouseEvents(true) is the only way, but as I said my app became useless.

@singuerinc Sorry for the delay, try using an older version of electron, i'm currently using 1.8.7

I've written a simple workaround class where you can choose whitelist or blacklist functionality for clicking through HTMLElements. It's available as electron-transparency-mouse-fix and also works for rounded corners! It was written from scratch today, so there still may be some issues.

Let's hope some of you can use this. It's also available through npm.

Edit: Doesn't work on linux :(

electron-transparency-mouse-fix demo gif

I have been grepping for the actual implementation of setIgnoreMouseEvents and I'm coming up dry besides finding the interface for its options. Getting a bit frustrated, could I tack this in for an explanation of where its behavior is actually defined?

And to contribute to the conversation, I was also using AHK as a means of workaround for my HUDs.
I didn't find the interface difficult to actually use and had to flip the setIgnoreMouseEvents to true in an event listener on my window when it was ready to show for everything to work as intended.

However I would like to understand the implementation, atleast find it.

If you're using Electron >3.0.0 (currently in beta) and you only need totally-transparent areas to be click-through-able, try the setWindowShape API introduced in #13789.

Looks like is not available on Mac.

@etisdew I believe what you're looking for can be found in atom/browser/native_window_views.cc (Windows/Linux) and in atom/browser/native_window_mac.mm (Mac).

Some people in this thread already proposed adding click-through based on transparency using the GPU, but would that really be useful? Most windows need a shadow to make window hierarchy clear. I've been working on an always-on-top floating widget/helper tool which really needs the shadows to stand out. Since these have an alpha>0, click through would be impossible. After working some more on the library posted above, I found out that most of the language features already exist to support native click-through.

Would it be possible to implement the way this library works natively?

JS/CSS equivalent

body {pointer-events: none}
window.addEventListener('mousemove', event =>
  if (event.target === document.documentElement) // <html>-element
    setIgnoreMouseEvents(true, {forward: true)   // {forward: true} keeps generating MouseEvents
  else
    setIgnoreMouseEvents(false)
)

The pointer-events CSS rule is standardized and prevents elements from being the event.target. You may add something like {transparent: true, clickThrough: 'pointer-events'} to the BrowserWindow options to activate this feature.

There's more to it when actually implementing it and supporting drag-events etc, but it doesn't seem to cause anything near a bottleneck. MouseEvents are generated anyhow, so performance shouldn't really be impacted. The ignoreMouseEvents state can be cached so only mouseenter/mouseleave triggers native window code.

animated png <a href="recorded@60fps">recorded@60fps</a>, <a href="played@60fps">played@60fps</a>

Edit: This piece of code would actually be enough if setIgnoreMouseEvents worked properly cross-platform. Currently it's a combination of workarounds including polling the mouse at screen refresh rate instead of listening for events in certain circumstances.

Any news here? 🙃

@metaa I partially fixed it in Mac (looks more like a hack) with setIgnoreMouseEvents (Electron 3)

https://github.com/singuerinc/overlay/blob/master/app/components/helpers/mouseEvents.ts#L3

So basically every time you go over an element in your app you have to setIgnoreMouseEvents(false) and when you go out the opposite. So it's quite expensive depending on your app. I'd say that it works quite well, although sometimes it's really hard to debug since the entire Electron becomes "non-clickable", in that case you can't use the devtools.

MacOs with the current version of Electron doesn't seem to have the problems I encountered months ago on Windows / Linux. 🙌

This is a minimal setup which works out of the box for me:

const setIgnoreMouseEvents = require('electron').remote.getCurrentWindow().setIgnoreMouseEvents
addEventListener('pointerover', function mousePolicy (event) {
  mousePolicy._canClick = event.target === document.documentElement ?
    mousePolicy._canClick && setIgnoreMouseEvents(true, {forward: true}) :
    mousePolicy._canClick || setIgnoreMouseEvents(false) || 1
})
setIgnoreMouseEvents(true, {forward: true}) // BUG: this must be triggered after the devtools loaded IF you load the console 'detached'
body {pointer-events: none}
.clickable {pointer-events: auto}

I really love the way this uses native CSS functionality. You can make an item click-through on the fly within devtools, the code footprint is minimal and it's pretty good performance wise too. The way inheritance works in CSS also suits this use case.

@toonvanvr Does this work on any macOS version, provided that we use the latest Electron version, as you said?

@mynetx Unfortunately, I have no idea about that since macOS 10.14 Mojave is the only version I ever used. The key feature that needs to be supported is {forward: true} while the rest should be platform-independent.

I am using electron 4.0.0 with MacOs 10.14.5 and even if I used the {forward: true} I still cannot get the mouse event (even I listen on the mouseover events).
I used: win.setIgnoreMouseEvents(true, { forward: true}); but then all mouse event are blocked.
On win8.1 with electron 4.0.0 it is working.

I did notice this happens only when I have another window open beneath the current one
@toonvanvr - should it work? am I missing anything?

@david-winder-kaltura
I haven't really been been using Electron anymore for a while, but last time I checked, it worked great without opening the devTools. Once you open the console, it's a mess with race conditions etc. to keep the mouse events and transparency in check.

I was inspired by this solution to do the following in my project:

From main,

Listen for replies to the emitted "hideWindow" message:

const { ipcMain } = require('electron');

// emitter
ipcMain.on('hideWindow', () => {
  mainWindow.hide();
});

mainWindow = new BrowserWindow({
  webPreferences: {
    nodeIntegration: true
  },
  frame: false,
  transparent: true,
  hasShadow: false,
  ...
});

From your application,

If an element with the id mainElement is clicked, send a response to "hideWindow":

const { ipcRenderer } = window.require('electron');

// so that we can write window.require
declare global {
  interface Window {
    require: any;
  }
}

...

function hideWindow(event: any) {
  let hideWindow = true;

  // some looping so that we can check for the id on all parent/child elements
  event.path.map(object => {
    if (object.id == 'mainElement') {
      hideWindow = false;
    }
  });

  // let Electron know we want to hide the window
  hideWindow && ipcRenderer.send('hideWindow');
}

document.addEventListener('mousedown', hideWindow);

A downside

  • You need to add the id "mainElement" to all of your separate components. This may be annoying to maintain if you're rendering multiple separate elements.

What to take away from this

I found this to be a clean solution for an application that works similar to Spotlight. I can show the application using keyboard commands, and hide it if I ever click outside the area of actual DOM elements.

Have you all tried to set

app.commandLine.appendSwitch( 'disable-gpu-compositing' );

before the app ready event?

@DEDaniel Does it work?

@LauraAubin's solution works fairly well, I'm using it myself.

Another downside though, is the clicks don't actually propagate through the transparent area. So if the user is trying to click something below your window, they will have to click twice to actually accomplish it.

@vifird yes for me this is working on Windows 7 and 10 using Electron version 6.0.2.
I came upon this issue because I wanted to disable an area in my css grid and having it transparent.
After having the transparent area I realised that the underlying application didn't received any click events. Therefore I added the mentioned line in my main.js Electron file and the problem is solved.

An example can be found here.

Could anybody tell me if there is a way to capture the coordinates of the click through event?

I want to have a transparent overlay that is clickable through ( I achieved this using solutions from this thread ), but also want to capture the coordinates of those click throughs ( no clue on how to do this) . I would appreciate if anybody could tell me if this is possible and maybe point me toward the solution.
(Feeling a bit desperate, already spent multiple hours on trying to achieve this, but no result :( )

Could anybody tell me if there is a way to capture the coordinates of the click through event?

@codemanki Hey!

Given that your overlay expands the whole area that you want to capture, you should be able to get the coordinates of the mouse using some JS with the event handler such as onClick or even onMouseMove.

I whipped up a little Codepen demonstrating this, though there are multiple approaches you can take.

https://codepen.io/LauraAubin/pen/NWPKrrq

Also note that I believe this solution will only work if the transparent overlay covers the entire space your mouse will hover over. That is, this won't work if you click outside of the Electron app.

@LauraAubin hey! Thank you for your answer and demo :) . The thing is, once you set setIgnoreMouseEvents to true, the electron window doesn't detect mouse clicks at all ( kind of what you expect with setIgnoreMouseEvents). I tried capturing them in the same way as you demonstrated, but unfortunately the mouse click event doesn't even get into the BrowserWindow, it just gets through to whatever is behind the overlay.

Getting this to work made me want to instantly give up on this lib. Total waste of time and very frustrating, especially with -webkit-app-region being ignored with setIgnoreMouseEvents... what a mess. Fortunately I have a solution that is working for me.

Make sure to enable webPreferences.nodeIntegration, then in your HTML:

Css

body {pointer-events: none}
* {pointer-events: all;}
.draggable {-webkit-app-region: drag;}

Js

setIgnoreMouseEvents = window.require('electron').remote.getCurrentWindow().setIgnoreMouseEvents

var t

window.addEventListener('mousemove', event => {
  if (event.target === document.documentElement) {
    setIgnoreMouseEvents(true, {forward: true})
    if (t) clearTimeout(t)
    t = setTimeout(function() {
      setIgnoreMouseEvents(false)
    }, 150)
  } else setIgnoreMouseEvents(false)
})

The idea here is that you by default don't want to ignore mouse events. But, if the mouse ever moves over the html or body elements as event targets, we want to ignore clicks that may occur and pass-through them. This does not include any children of the body, which WILL receive clicks, and won't pass-through.

AKA body and HTML event targets => pass-through
Children of body => don't pass through

The timeout is necessary because if you mousemove from a pass-through element (like body or html) to a .draggable element (i.e. has -webkit-app-region applied), then it won't receive click events, because setIgnoreMouseEvents was never set back to false. So, we try to just set it to false by default (after timeout).

@singuerinc yes, if you enable disableHardwareAcceleration and set the app transparency to true, only solid and if you set the opacity to 0.1 will be clickable. Do take note about the slowdown on macs (check @adeperio's response)

This works on Windows10, but not on MacOSX.

Hey people. What's the agreed upon best practice for this nowadays, if any?

@nikkwong this is the only solution to work for me on both MacOS and Windows. You made my day!

@nikkwong, this causes the mouse to behave weirdly if interacting with the window behind the electron window's transparent area

It would be great if there were just a way to set a callback that returns true or false depending on whether you want to window to respond to clicks. On Mac, this could be implemented by conditionally return nil or self from https://github.com/electron/electron/blob/master/shell/browser/native_browser_view_mac.mm#L36.

@nikkwong answer worked for me too. I had to make some changes though:

const electron = require('electron');
const {ipcRenderer} = require('electron');
const BrowserWindow = electron.remote.BrowserWindow;
  setIgnoreMouseEvents = BrowserWindow.getAllWindows()[0].setIgnoreMouseEvents;

Then of when you create the window in main.js do it like this:

  const win = new BrowserWindow({
    width: 800,
    height: 600,
    frame: false,
    transparent: true,
    webPreferences: {
      nodeIntegration: true,
      enableRemoteModule: true,
    }
  })

because the transparent window is lost focus, so the

window.addEventListener('mousemove', cb)

can not be triggered

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ThorstenHans picture ThorstenHans  ·  3Comments

rhnorskov picture rhnorskov  ·  3Comments

wsangtoki picture wsangtoki  ·  3Comments

tengyifei picture tengyifei  ·  3Comments

dangan-ronpa picture dangan-ronpa  ·  3Comments