Disabled/hidden menu appears anyway after upgrade to 4.0.0-beta.8

[zadam]

• Output of node_modules/.bin/electron --version: v4.0.0-beta.8
• Operating System (Platform and Version): Ubuntu Linux 18.10
• Output of node_modules/.bin/electron --version on last known working Electron version (if applicable): v4.0.0-beta.7

Expected Behavior
No application menu appears.

Actual behavior
Menu appeared, additionally it's invisible before clicking on it (see screenshots).

To Reproduce

$ git clone https://github.com/zadam/trilium -b master
$ npm install
$ npm run start-electron

Screenshots

The weird thick title bar is actually a menu after clicking on it:

This is the menu after clicking on it:

Additional Information

To be clear my app doesn't have any app menu so the menu isn't enabled. This worked as expected with 4.0.0-beta.7 and earlier versions.

[welcome]

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

To help make it easier for us to investigate your issue, please follow the contributing guidelines.

[ckerr]

This is possibly fixed by #15878 which will be in 4.0.0-beta.9.

Could you please retest with that once it's released?

[ckerr]

OH -- also, thank you for testing your app with the betas! ❤️

[zadam]

Yes, #15878 does explain why the menu looks invisible (font color is wrong).

But it doesn't explain why menu shows up in the first place since it's disabled and properly didn't show up in beta.7 and earlier. I create the window like this:

const win = new electron.BrowserWindow({ ... my config ... });
win.setMenu(null);

win.setMenu(null) should hide the menu AFAIK.

This was when I started electron ./node_modules/.bin/electron .
Then I thought I will also test it built with electron packager and surprisingly, that one didn't have the menu (which is correct).

So it's probably not a big issue, but still a bit surprising and it's a change from the earlier releases.

[ckerr]

This works in 6487466 but not in 7cc7d4a, so I think #15094 that caused this regression.

@nitsakh I'm happy to investigate this, but if you have an idea of the cause, do you want this ticket?

[vladimiry]

There was the same problem introduced with 3.0.8 #15601 and it got fixed there. But now the final v4 release is affected.

[joehonton]

I can confirm that this was working in 3.10 but is not working in 4.0.0 on Windows and Linux.

var browserWindow = new Electron.BrowserWindow(options);
browserWindow.setMenu(null);

In my case I have one browser window that should have a menu and several others -- acting as modeless dialogs for preferences and tools -- that should not. I use setMenu(null) on these modeless windows.

[TheFeelTrain]

Same issue here after updating to 4.0.0 on Arch Linux with KDE Plasma 5.

[ventr1x]

Any info regarding this?

setMenu(null) is not working at all.
Overwriting the menu template afterwards works, but results in the debug menu appearing for a few seconds until initialization.

"electron": "^4.0.1" on macOS

[andrewheadricke]

stumbled onto same issue. v4.0.1 on linux

[vladimiry]

Any info regarding this?

As an ugly workaround, you can set autoHideMenuBar to true creating the BrowserWindow. So menu will remain hidden until user presses alt key.

[bluenote10]

I have a similar issue (menu is always visible despite setMenu(null), no black font color). Tested with 4.0.1 and 4.0.4 under Linux.

[Ajeey]

Any info regarding this?

As an ugly workaround, you can set autoHideMenuBar to true creating the BrowserWindow. So menu will remain hidden until user presses alt key.

After you've done the above, an even uglier workaround is to disable the alt key press -

document.addEventListener('keydown', (event) => {
    if(event.altKey) {
        event.preventDefault();
        return;
    }
});

Tested this on 4.0.8 and works 💃

[jacobq]

The work-around I am using is to call win.setMenuBarVisibility(false). That seems to avoid the problem with the Alt key revealing the menu. Am I missing something?

[pronebird]

@jacobq yep you're missing the fact that it does not work on Ubuntu Linux. The only way to hide the menu is to pass autoHideMenuBar: true in Window options. win.setMenuBarVIsibility(false) does nothing at all and it's still possible to get that menu with Alt key.

[jacobq]

@pronebird

it does not work on Ubuntu Linux

Really? Try my minimal demo here. It works for me on Debian. What is the difference?

GIF

[Ajeey]

@jacobq Try hiding for a child window

[electron-triage]

Thank you for taking the time to report this issue and helping to make Electron better.

The version of Electron you reported this on has been superseded by newer releases.

If you're still experiencing this issue in Electron 6.x.y or later, please add a comment specifying the version you're testing with and any other new information that a maintainer trying to reproduce the issue should know.

I'm setting the blocked/need-info label for the above reasons. This issue will be closed 7 days from now if there is no response.

Thanks in advance! Your help is appreciated.

[joehonton]

This is the code that hid the menu from the window. It was working in 3.10 but broke in 4.0.0 --

var browserWindow = new Electron.BrowserWindow(options);
browserWindow.setMenu(null);

I have just now tested this on these versions all of which still exhibit the broken behavior:

• 4.0.1
• 5.0.13
• 6.1.7
• 7.1.13
• 8.0.1

This ticket should be kept opened.

[jacobq]

Does the Menu.setApplicationMenu(null) work-around mentioned in the linked issue help?

[ventr1x]

"We completely ignored this issue for nearly two years, please test again if it magically disappeared so we can keep ignoring it.Thanks, your truly. useless bot."

[joehonton]

@jacobq The Menu.setApplicationMenu(null) purported work-around does not work.

There appears to be two scenarios intermingled in this discussion. The one I'm reporting is where I have an application window that does have a menu, and a second window, for informational purposes, that does not.

This is the desired pseudo code:

menu = Electron.Menu.buildFromTemplate(template);
Electron.Menu.setApplicationMenu(menu); 
. . .
myApplicationWindow = new Electron.BrowserWindow(options);
. . .
mySecondWindow = new Electron.BrowserWindow(options);
mySecondWindow.setMenu(null);

[jacobq]

@jacobq The Menu.setApplicationMenu(null) purported work-around does not work.

OK, so IIUC the reason in your case is that Menu.setApplicationMenu(menu) affects all windows (on Windows / Linux) but you need to control specific windows.

Would you be willing to share an electron-fiddle demonstrating the problem? I would be curious to see it since I have run into similar problems in the past but was always able to work around them somehow (e.g. wait for ready event).

[joehonton]

I have worked through the issue stripping down the code to bare essentials, TL;DR I am now satisfied that browserWindow.setMenu(null) does work as expected.

The longer story is that my app has a lengthy initialization phase (approximately 1000ms to 1500ms depending on the file it's opening), which causes a race condition between creating the menu with Electron.Menu.buildFromTemplate and creating the first and second browser windows. This triggers an occasional artifact where the setMenu(null) for the second window is overridden by setMenu(menu) being called on the first window.

It would be OK with me to close this ticket, but the real solution would be to change new BrowserWindow(options) to have an option that explicitly states that the window should not have a menu.

[electron-triage]

The Electron version reported on this issue is no longer supported. See our supported versions documentation.

If this is still reproducible on a supported version, please open a new issue with any other new information that a maintainer should know.

Thank you for taking the time to report this issue and helping to make Electron better! Your help is appreciated.