Unresponsive or laggy main menu
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
36.3.1
What operating system(s) are you using?
Windows
Operating System Version
Windows 11 23H2
What arch are you using?
x64
Last Known Working Electron version
No response
Expected Behavior
When moving the mouse cursor over items in the main menu, the user expects the submenu items to be shown in a responsive manner, see example from Notepad (both modern and classic):
https://github.com/user-attachments/assets/481eb092-5590-404a-9333-0cbf6bcd167b
https://github.com/user-attachments/assets/478c047d-56a4-46d8-bcad-afa08ef84a7b
Actual Behavior
Sometimes when mouse cursor over items in the main menu the submenu doesn't change, even though the user is hovering over another menu item, see demo:
https://github.com/user-attachments/assets/8c752d7e-2668-4a5d-bd4b-17a3e79387b8
If this is by design, to have a larger hover area for the existing submenu than visible, please provide an option to disable it and provide the user with the more expected native experience.
Testcase Gist URL
https://gist.github.com/aidinabedi/6b84b9f5dc61c86599892345b9fa2738
Additional Information
No response
I can do this, but can you tell me where this problem is happening?
I can do this, but can you tell me where this problem is happening?
@tajagn01 Notice that sometimes when the mouse cursor hovers over some of the menu item (like the menu item Edit at 0:02s), the submenu for that menu item doesn't drop down.
Thanks for reporting! This looks like a bug.
Could you please use Electron Fiddle to create a minimal reproducible example and publish it as a gist?
Hello @aidinabedi. Thanks for reporting this and helping to make Electron better!
Would it be possible for you to make a standalone testcase with only the code necessary to reproduce the issue? For example, Electron Fiddle is a great tool for making small test cases and makes it easy to publish your test case to a gist that Electron maintainers can use.
Stand-alone test cases make fixing issues go more smoothly: it ensure everyone's looking at the same issue, it removes all unnecessary variables from the equation, and it can also provide the basis for automated regression tests.
Now adding the https://github.com/electron/electron/labels/blocked%2Fneed-repro label for this reason. After you make a test case, please link to it in a followup comment. This issue will be closed in 10 days if the above is not addressed.
Thanks for reporting! This looks like a bug.
Could you please use Electron Fiddle to create a minimal reproducible example and publish it as a gist?
@nikwen It's just the default main menu: https://gist.github.com/aidinabedi/6b84b9f5dc61c86599892345b9fa2738
Thanks! It's always helpful to have shared code to reference.
Hello @nikwen! Were you able to reproduce the issue?
@aidinabedi I haven't tried to reproduce it on my end yet. I am often the person collecting all the necessary info for bug reports. Then any Electron team member is welcome to work on any issue they want to work on. That often ends up being someone else than me.
I can reproduce this behavior on a fresh default app installation. The inconsistent lag creates a jarring user experience.
The issue appears to be an incorrectly sized invisible hover area for the menu overlay.
Steps to reproduce:
- Hover over the top 1-2px of the menu bar → Menu opens instantly
- Hover over the bottom 1-2px of the menu bar → Menu doesn't open at all
- Hover over the middle area → Inconsistent behavior depending on whether the cursor crosses into the top half
Expected behavior:
The entire visible menu bar should have a consistent hover response with uniform timing.
Suggested fix:
Verify that the hover detection area matches the visual boundaries of the menu bar component.
Unfortunately the root cause for this is out of our control - it began with CR2023 (Chrome's 2023 UI Refresh), which had a fair host of issues (see e.g. https://issues.chromium.org/issues/40067694).
I suggest filing a bug upstream at https://issues.chromium.org/issues - when they fix it, we'll inherit that fix.