max-mapper / max-mapper/menubar
Menubar hide event doesn't have enough time to propagate to renderer
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 6.8k
- Forks
- 363
- PR merge metrics
- No merged PRs in 30d
Description
This is not necessarily a bug in menubar but I wanted to document it here as it is a practical issue and perhaps there is a workaround or a different way to do this.
My menubar application has an animation effect when it is opened (fade in) and when it is closed (hidden) I need to reset the effect (basically set opacity to 0 with no animation).
So I need to propagate the hide event to the renderer (I do something like this):
menu.on("hide", => menu.window.webContents.send("hide"))
The problem is that this doesn't always have time to reach the renderer and apply the changes (opacity: 0) before the window is hidden. So then when I click the menubar again I momentarily see the menubar in it's fully opaque state then it disappears (opacity: 0) and then the fade in transition happens. It's a race condition so sometimes it works fine, sometimes it doesn't.
I have a hacked a fix for this by putting a setTimeout around menubar.window.hide() in the menubar module and that works for my purposes but perhaps there is a better way to do this?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the menu.on("hide") handler, webContents.send("hide"), and the menubar.window.hide() call described in the issue. Reproduce the race between renderer updates and window hiding, then document or verify a reliable behavior in which the opacity reset reaches the renderer before the window is hidden.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- electron, typescript
- Domain
- desktop
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100