max-mapper / max-mapper/menubar

Unexpected Behavior in 'Tips' Documentation -- re: window.hide() & always-on-top

Open
#324 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
6.8k
Forks
363
PR merge metrics
No merged PRs in 30d

Description

Description

My overarching goal is an app that is a "pure" menubar, targeting specifically macOS users, with the purpose being to show at-a-glance data in the menubar along with additional detail & quick "controls" when the app is open. I want it to function similar to most macOS menubar apps (ie 1Password) -- when focus is lost, the window should hide completely.

The 'Tips' section of the documentation specifies the following:

Use mb.on('focus-lost') if you would like to perform some operation when using the option browserWindow.alwaysOnTop: true

Steps to Reproduce the Problem
  1. Based on the 'tips' part of the README, I used the following code to cause the window to hide when focus is lost:

mb.on('focus-lost', () => { mb.window.hide(); });

  1. With the menubar app open, click anywhere away from the menubar app (causing it to lose focus).
  2. After closing the app via clicking outside of it [ie loss of focus], now attempt to re-open the menubar app via clicking it in the macOS menubar.
  3. Note that it does not open upon clicking it; a second click is required to get it to open.
Expected Behaviour

After closing the app via clicking outside of it [ie loss of focus], any future click on the app in the macOS menubar should re-activate & display the app/window.

Actual Behaviour

After closing the app via clicking outside of it [ie loss of focus], any future click on the app in the macOS menubar will intermittently (seems to toggle/alternate) have no effect / be a no-op click (window does not display). Clicking it a second time opens the window.

Specifications
  • Menubar version: 9.0.2
  • Platform: macOS Big Sur (11.2.1)
  • Electron version: 9.4.3
Other information

It appears that using the following code, instead of the code above, actually causes the behavior to be as expected -- ie it resolves the issue -- so maybe this "issue" can just be 'fixed' via simply updating the documentation, I'm not sure.

mb.on('focus-lost', () => { mb.hideWindow(); });

If nothing else, I'd like to understand why this works & the approach that I tried initially does not; and if there is a way to make my initial approach work I'd love to hear & learn/understand it (ie do I need to call/init the window again somehow, or listen for menubar click manually & call show(), or similar). :)

Thank you very much; this is a fantastic project and I very much appreciate all the work that has gone into it! It's really quite nice -- thank you! :)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the README's Tips section and compare its focus-lost example using browserWindow.alwaysOnTop with the reported window.hide() and mb.hideWindow() behavior. Reproduce the macOS menubar interaction if possible, then update the documentation so the supported approach and expected click behavior are clear.

Written by the indexing model from the issue text.

Assessment

Tech stack
electron, typescript
Domain
desktop, documentation
Issue type
Documentation
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.