Issue 1:
Preflight Checklist

I have read the Contributing Guidelines for this project.

I agree to follow the Code of Conduct that this project adheres to.

I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Electron Version

11.3.0

What operating system are you using?

macOS

Operating System Version

macOS Big Sur 11.5.1

What arch are you using?

arm64 (including Apple Silicon)

Last Known Working Electron version

No response

Expected Behavior

When the frame: false option is passed to the new BrowserWindow() options, all of the window is a canvas for HTML that is clickable.

Actual Behavior

The top ~20 pixels of the frameless window is not clickable, and doesn't have events. It's as if the title bar was there, but invisible. This is the code:

const { app, BrowserWindow } = require("electron");

app.on("ready", () => {
const child = new BrowserWindow({ frame: false });
child.loadURL("https://github.com");
child.once("ready-to-show", () => {
child.show();
});
});

See a recording of the bug in action, expected the whole icon/button to be hoverable+clickable but seems like something is "covering" them:

electron-bug.mp4

Testcase Gist URL

https://gist.github.com/franciscop/20a6fbd380ad10678e512f14c76be125

Additional Information

Something interesting is that, playing with the option titleBarStyle you can get one version where this particular issue is fixed (BUT it requires you to show the buttons on hover, which of course it's an impossible requirement in many cases, so it's still a bug):

const { app, BrowserWindow } = require("electron");

app.on("ready", () => {
const child = new BrowserWindow({
frame: false,
// We don't want the buttons, but at least this makes more real estate clickable?
titleBarStyle: "customButtonsOnHover"
});
child.loadURL("https://github.com");
child.once("ready-to-show", () => {
child.show();
});
});

See how now you can hover on all the elements, BUT it also displays the buttons on hover:

electron-almost-fixed.mp4

I tried hidden and hiddenInset but they oddly enough do show the controls and they still have the previous issue as the commented here originally (or even worse in the case of hiddenInset).

Related bugs:

This bug in menubar is definitely the same thing.

I found another slightly related but probably different bug since it's in a different platform, so I believe it might be a different thing (the video linked is dead so cannot verify).

Code dive-in

I'm way out of my depth here, but it seems this line of code is the one making the title bar transparent when frame: false:

if (transparent() || !has_frame()) {
// Don't show title bar.
[window_ setTitlebarAppearsTransparent:YES];
[window_ setTitleVisibility:NSWindowTitleHidden];

And then this conditional makes it "visible" if it's not customButtonsOnHover? Maybe? (as I said, unfortunately I can report the bug but not sure if I follow the correct code for the bug here):

if (title_bar_style_ == TitleBarStyle::kCustomButtonsOnHover)
[buttons_proxy_ setVisible:visible];
else
InternalSetWindowButtonVisibility(visible);

Issue 2:
Preflight Checklist

I have read the Contributing Guidelines for this project.

I agree to follow the Code of Conduct that this project adheres to.

I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem Description

IIUC, when using the app.requestSingleInstanceLock(); function in our electron main process, when it returns false we would usually exit the second created process, since the event will be forwarded to the first instance. My issue here is that when exiting the second process, I may want to get feedback from the main instance to know what exit code to return with. Say I wanted to open a resource but it failed, I would like my second process to exit with code != 0. Maybe a CLI argument passed was bogus as well, which case I'd like to exit with code != 0 again.

Proposed Solution

Since it would be weird to change the return type of app.requestSingleInstanceLock(), maybe add a new app.waitSingleInstanceResponse() that would return a promise with the value set from a new callback function in the second-instance event: event.setResponse(data). Data type is left to implementers to decide what is easier/better. String is fine with me, or serialization could be done by the framework, I don't know what's best.

Alternatives Considered

I would have liked to tap into any already involved IPC mechanism used for that feature, but I don't know where to look for that, and it feels a bit hacky IMO.

Additional Information

This new flow would allow to put most argument parsing into the main single instance process, and avoid thinking about how to break the processing in the temporary second process and then maybe duplicate parsing again in the main instance. Please tell me if I just approach the issue from the wrong angle as well.