macOS Mojave: Unclickable region in windows with "hiddenInset" title bar

[javan]

Expected Behavior
Clicking any region of the window should activate the element under the cursor.

Actual behavior
A small region in the top-center of the window isn't clickable.

To Reproduce

• Clone and run https://github.com/javan/electron-quick-start/tree/hidden-inset-mojave
• Click the black bar at the top of the window. It should turn purple while the mouse is down.
• Click the top-center of the black bar and note that it does't turn purple.

$ git clone https://github.com/javan/electron-quick-start.git -b hidden-inset-mojave
$ npm install
$ npm start

Screenshots
macOS Mojave 10.14 Beta (18A384a) 👎

macOS High Sierra 10.13.6 👍

Additional Information
This issue impacts any application with critical navigation elements on the top of the page. For us (Basecamp 3), the "Hey!" menu is very difficult to click:

<notch-joke>

</notch-joke>

It's likely that Mojave will be released this week during the Apple Special Event on September 12.

[javan]

/cc @MarshallOfSound (I think you might be looking into Mojave issues?)

[javan]

It appears that the unclickable region is where the title would be if the window had a standard title bar.

In the gif below there are two stacked windows. The rear window has a standard title bar, and the front window has a hiddenInset title bar. Both have their title set to X.

You can see that the unclickable area of the front window is the same size as the X in the title. Setting a longer title results in a larger unclickable region.

[javan]

Setting the title to an empty string helps, but doesn't totally fix the problem. There's still a small unclickable region about the size of a single character.

[tommoor]

Setting the title to an empty string helps

This doesn't seem like a workable solution considering that title is reflected in all sorts of other areas in the OS? CMD+Tab / Window menu etc?

[javan]

This doesn't seem like a workable solution

It's a workaround, not a solution. YMMV

title is reflected in all sorts of other areas in the OS? CMD+Tab / Window menu etc

I believe CMD+Tab displays the app name (app.getName()) not the window title.

[tommoor]

If it helps we're running Electron 1.8 and also seeing this issue on Mojave, so whatever the issue is has been there for a while - not unique to 3.X and the newer releases

[lehni]

I'm seeing this issue also in https://marketplace.visualstudio.com/items?itemName=lehni.vscode-titlebar-less-macos

[tommoor]

This issue still exists in 5.X and 6.X in macOS Catalina

[bpasero]

This would block microsoft/vscode#12377 in VSCode.

[jlindberg-oss]

This definitely seems to be an active problem, I am even having problems with input elements not working correctly in the top region when hiddenInset is used on MacOS High Sierra.

Any chance of the workaround developed by @knopp in microsoft/vscode#12377 (comment) making it into Electron?

[astoilkov]

We are experiencing what I believe are additional side effects coming from the same bug. I have described them in hiddenInset breaks mouse interactions in the first 38px of the window.

[fabiospampinato]

Could this issue be prioritized higher please? @codebytere @MarshallOfSound

Attempting to work around this issue by setting the title to an empty string has all sorts of weird consequences:

• Still a small area of the window will be unresponsive to clicks.
• Windows with empty titles won't be listed in the list of windows under the "Windows" app menu or in the app's menu from the Dock.
• Switching between windows via App Exposé can be difficult if all windows look the same and you have no title to help you distinguish them.

And using a titlebar can really hinder the user experience for some apps, as they would look more like a website wrapped in an Electron shell with a quick script rather than something that's supposed to integrate much better with the OS.

[MarshallOfSound]

This is currently expected and unfixable behavior. The good news is there is an easy workaround. You can use the hidden title bar style and use the trafficLightPosition option in the BrowserWindow constructor to position the traffic lights wherever you want. The coordinates that are equivalent to hiddenInset are as follows:

const w = new BrowserWindow({
  frame: false,
  titleBarStyle: 'hidden',
  trafficLightPosition: {
    x: 14,
    y: 22,
  }
});

The trafficLightPosition API is available in Electron 8.2 and higher.

[fabiospampinato]

@MarshallOfSound that seems to work perfectly for me, thanks!

Are there any drawbacks in removing the titlebar this way over via setting "hiddenInset"? If there aren't shouldn't Electron just execute the code you provided when the "hiddenInset" value is set?

P.S. The precise coordinates at which the traffic lights get positioned with "hiddenInset" seems to be { x: 12, y: 22 } on my system.

[MarshallOfSound]

Are there any drawbacks in removing the titlebar this way over via setting "hiddenInset"? If there aren't shouldn't Electron just execute the code you provided when the "hiddenInset" value is set?

No drawbacks that I'm aware of, it's functionally different and is more likely to have some strange bugs. E.g. Historically we've had to work around edge cases with fullscreen mode and such, but in general it's a perfectly reasonable replacement. We might flip the implementation for hiddenInset at some point but right now there's no real driver for it 🤷

P.S. The precise coordinates at which the traffic lights get positioned with "hiddenInset" seems to be { x: 12, y: 22 } on my system.

Hm, I pulled those numbers from what I assume is a reliable source 🤔 Where did you get x=12 from?

[fabiospampinato]

Hm, I pulled those numbers from what I assume is a reliable source 🤔 Where did you get x=12 from?

Trial and error when comparing before and after screenshots. Where does that other coordinate come from?

[lehni]

@fabiospampinato @MarshallOfSound perhaps you are both on different versions of macOS?