This repository was archived by the owner on Feb 25, 2025. It is now read-only.
Unregister the FlutterWindowsView on its destruction#39824
Merged
yaakovschectman merged 3 commits intoflutter:mainfrom Feb 24, 2023
Merged
Unregister the FlutterWindowsView on its destruction#39824yaakovschectman merged 3 commits intoflutter:mainfrom
yaakovschectman merged 3 commits intoflutter:mainfrom
Conversation
loic-sharma
reviewed
Feb 23, 2023
| @@ -50,6 +50,9 @@ FlutterWindowsView::FlutterWindowsView( | |||
|
|
|||
| FlutterWindowsView::~FlutterWindowsView() { | |||
| DestroyRenderSurface(); | |||
Member
There was a problem hiding this comment.
This is fine but I think it'd be preferable if the view was deregistered from the engine before its state is torn down. This way the engine does not point to a "bad" view.
Contributor
Author
There was a problem hiding this comment.
What are you considering when the state is torn down? At the start of the destructor being called?
Member
There was a problem hiding this comment.
I meant that I would deregister the view before destroying the render surface. So yup, deregistering the view at the start of the destructor would work
yaakovschectman
force-pushed
the
unregister_windows_view
branch
from
3f2f0e0 to
000e03a
Compare
engine-flutter-autoroll
added a commit
to engine-flutter-autoroll/flutter
that referenced
this pull request
Feb 24, 2023
engine-flutter-autoroll
added a commit
to engine-flutter-autoroll/flutter
that referenced
this pull request
Feb 24, 2023
engine-flutter-autoroll
added a commit
to engine-flutter-autoroll/flutter
that referenced
this pull request
Feb 24, 2023
yaakovschectman
added a commit
that referenced
this pull request
Mar 24, 2023
This reverts commit d2d00be.
auto-submit bot
pushed a commit
that referenced
this pull request
Mar 24, 2023
#40607) Revert "Unregister the FlutterWindowsView on its destruction"
eyebrowsoffire
pushed a commit
to eyebrowsoffire/engine
that referenced
this pull request
Mar 27, 2023
…#39824)" (flutter#40607) Revert "Unregister the FlutterWindowsView on its destruction"
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
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.
FlutterWindowsViewowns both theFlutterWindowsEngineandWindowBindingHandleras unique pointers, so each is released upon its destruction. However, in the brief time between the release of the handler and the engine, the engine may attempt to call a method that expects the handler to exist.Solve this by unsetting the engine's view from
FlutterWindowsView::~FlutterWindowsView, which should complete before destructing its members. Include a unit test to verify that the view is unset by the time the handler is released.flutter/flutter#121189
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.