Fix macOS main menu not working before refocus.#994
Merged
xStrom merged 2 commits intolinebender:masterfrom May 31, 2020
Merged
Fix macOS main menu not working before refocus.#994xStrom merged 2 commits intolinebender:masterfrom
xStrom merged 2 commits intolinebender:masterfrom
Conversation
Member
|
I'm confused by this; I haven't been able to reproduce the original bug? When the application launches, I'm able to interact with the menus? |
Member
Author
|
Are you on macOS Catalina? It's 100% reproduction for me on Catalina. |
Member
|
no I'm on 10.14.6 |
Member
Author
|
I'm not fully sure if Catalina is the cause here, but I did see one person mention it on Stack Overflow that for them the menu issue appeared in Catalina and they needed a new fix. @totsteps could you check if this PR here fixes the menu issue for you? |
Collaborator
|
Thanks for the fix. I double-checked with the current master, the menu is not accessible when running examples! I can confirm that this PR fixes issue. |
madsmtm
added a commit
to madsmtm/winit
that referenced
this pull request
Apr 6, 2021
This fixes the main menu not responding until you refocus, at least from what I can tell - though we might have to do something similar to linebender/druid#994 to fix it fully?
madsmtm
added a commit
to madsmtm/winit
that referenced
this pull request
Apr 6, 2021
This fixes the main menu not responding until you refocus, at least from what I can tell - though we might have to do something similar to linebender/druid#994 to fix it fully?
8 tasks
madsmtm
added a commit
to madsmtm/winit
that referenced
this pull request
Apr 29, 2021
This fixes the main menu not responding until you refocus, at least from what I can tell - though we might have to do something similar to linebender/druid#994 to fix it fully?
ArturKovacs
pushed a commit
to rust-windowing/winit
that referenced
this pull request
Apr 29, 2021
) * MacOS: Only activate after the application has finished launching This fixes the main menu not responding until you refocus, at least from what I can tell - though we might have to do something similar to linebender/druid#994 to fix it fully? * MacOS: Remove activation hack * Stop unnecessarily calling `makeKeyWindow` on initially hidden windows You can't make hidden windows the key window * Add new, simpler activation hack For activating multiple windows created before the application finished launching
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR fixes the issue on macOS where the application menu can't be interacted with until the window loses and regains focus.
There are some pretty wild workarounds out there for this, like setting a timer to automatically refocus the window. However as shown in this PR it can be done in an easier fashion. From the surface it seems to be mostly about not letting the app activate before the menu is all set up.
Fixes #753.