-
Notifications
You must be signed in to change notification settings - Fork 29.7k
[Windows] Make lifecycle manager updates atomic #164872
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
mattkae
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks reasonable to me! If someone else who has more opinions about the system wants to comment, please be my guest :)
engine/src/flutter/shell/platform/windows/flutter_windows_unittests.cc
Outdated
Show resolved
Hide resolved
|
Note that this fixes the window being stuck in focus/unfocus loop in the multi-window branch when switching between windows. |
hbatagelo
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! In the reference app, I got the focus switch loop fixed by parenting the FocusTraversalGroup of each root view to the root focus scope, but I wasn't aware that the actual cause could be in the lifecycle manager!
engine/src/flutter/shell/platform/windows/windows_lifecycle_manager.cc
Outdated
Show resolved
Hide resolved
@hbatagelo, those are actually two different loops. The one here causes the following issue: focus.movIt is due to application temporarily entering inactive state while switching between two windows. It is unrelated to focus traversal loop, which is caused by nested scopes. |
engine/src/flutter/shell/platform/windows/windows_lifecycle_manager_unittests.cc
Outdated
Show resolved
Hide resolved
engine/src/flutter/shell/platform/windows/windows_lifecycle_manager.h
Outdated
Show resolved
Hide resolved
loic-sharma
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice fix and cleanup, thanks!
…tests.cc Co-authored-by: Matthew Kosarek <[email protected]>
…nager.cc Co-authored-by: Harlen Batagelo <[email protected]>
…nager_unittests.cc Co-authored-by: Loïc Sharma <[email protected]>
…nager.h Co-authored-by: Loïc Sharma <[email protected]>
c03f6f0 to
afb71ef
Compare
Required for multi-window. On windows the `LifecycleManager` currently sends the lifecycle event as soon as windows message is processed. This however causes problems when changing focus between application windows. When switching focus from HWND1 to HWND2, HWND1 first gets unfocused, followed by HWND2 getting focused. After HWND1 gets unfocused, `LifecycleManager` immediately notifies the framework that the application is inactive, which is wrong as the application never went into inactive state, followed by subsequent call to put the application in resumed state when HWND2 is focused. Because this happens very quickly, sometimes focus manager gets into inconsistent state. To resolve this `LifecycleManager` should gather the all the changes while window sends the messages and then notify the framework atomically in next run loop turn. This PR also simplifies the logic in `LifecycleManager` through which the application state is derived from window states. This PR removes engine forcing `resumed` lifecycle state at startup. I'm not entirely sure what the point of this was - the state can and should be determined solely from window states, this just seems to muddy the state logic. Also it happens before the framework is even listening to state changes. The mutex in `WindowsLifecycleManager` is removed. Not sure why it was there. ## Pre-launch Checklist - [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [x] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [x] I signed the [CLA]. - [x] I listed at least one issue that this PR fixes in the description above. - [x] I updated/added relevant documentation (doc comments with `///`). - [x ] I added new tests to check the change I am making, or this PR is [test-exempt]. - [x] I followed the [breaking change policy] and added [Data Driven Fixes] where supported. - [x] All existing and new tests are passing. If you need help, consider asking for advice on the #hackers-new channel on [Discord]. <!-- Links --> [Contributor Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview [Tree Hygiene]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md [test-exempt]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests [Flutter Style Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md [Features we expect every widget to implement]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement [CLA]: https://cla.developers.google.com/ [flutter/tests]: https://github.com/flutter/tests [breaking change policy]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes [Discord]: https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md [Data Driven Fixes]: https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md --------- Co-authored-by: Matthew Kosarek <[email protected]> Co-authored-by: Harlen Batagelo <[email protected]> Co-authored-by: Loïc Sharma <[email protected]>
Required for multi-window.
On windows the
LifecycleManagercurrently sends the lifecycle event as soon as windows message is processed. This however causes problems when changing focus between application windows.When switching focus from HWND1 to HWND2, HWND1 first gets unfocused, followed by HWND2 getting focused. After HWND1 gets unfocused,
LifecycleManagerimmediately notifies the framework that the application is inactive, which is wrong as the application never went into inactive state, followed by subsequent call to put the application in resumed state when HWND2 is focused. Because this happens very quickly, sometimes focus manager gets into inconsistent state.To resolve this
LifecycleManagershould gather the all the changes while window sends the messages and then notify the framework atomically in next run loop turn.This PR also simplifies the logic in
LifecycleManagerthrough which the application state is derived from window states.This PR removes engine forcing
resumedlifecycle state at startup. I'm not entirely sure what the point of this was - the state can and should be determined solely from window states, this just seems to muddy the state logic. Also it happens before the framework is even listening to state changes.The mutex in
WindowsLifecycleManageris removed. Not sure why it was there.Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.