Skip to content

Hot Restart should dispose all previous Platform Views (macOS) #163439

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

Merged
merged 2 commits into from
Feb 19, 2025

Conversation

PaulAllanSturm
Copy link
Contributor

@PaulAllanSturm PaulAllanSturm commented Feb 16, 2025

When using Platform Views on macOS, performing a Hot Restart throws an exception with message "trying to create an already created view". This is because the old Platform Views are not cleaned up. So, here we dispose of the old Platform Views as part of the Hot Restart process.

Fixes issue: #110381

Pre-launch Checklist

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@chinmaygarde
Copy link
Member

cc @cbracken @jonahwilliams

@jonahwilliams jonahwilliams requested a review from knopp February 18, 2025 20:12
@@ -170,4 +170,11 @@ - (void)disposePlatformViews {
_platformViewsToDispose.clear();
}

- (void)reset {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be sufficient but adding @knopp to verify.

Copy link
Member

@knopp knopp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about the test. Wouldn't it be easier to create say 2 platform views, call reset and then try to get the views by Id to see if the result is nil for both of them, instead of testing failure when creating view with identical Id?

@PaulAllanSturm
Copy link
Contributor Author

I'm not sure about the test. Wouldn't it be easier to create say 2 platform views, call reset and then try to get the views by Id to see if the result is nil for both of them, instead of testing failure when creating view with identical Id?

I'm happy to do it either way, but the way it is now is intended to match what was happening with the original bug report. I.e., a platform view was created, a Hot Restart was done, and then another platform view with the same id gets created. The test is basically saying that without calling "reset()", you get the exception as described in the original bug report, and then with the "reset()", the problem is resolved.

@PaulAllanSturm PaulAllanSturm requested a review from knopp February 18, 2025 20:48
@knopp
Copy link
Member

knopp commented Feb 18, 2025

I'm not sure about the test. Wouldn't it be easier to create say 2 platform views, call reset and then try to get the views by Id to see if the result is nil for both of them, instead of testing failure when creating view with identical Id?

I'm happy to do it either way, but the way it is now is intended to match what was happening with the original bug report. I.e., a platform view was created, a Hot Restart was done, and then another platform view with the same id gets created. The test is basically saying that without calling "reset()", you get the exception as described in the original bug report, and then with the "reset()", the problem is resolved.

In theory somebody can break the reset and change view creation to overwrite existing view (or just fail silently), the test will still pass but the behavior will be wrong. I don't feel too strongly about this either though.

@PaulAllanSturm
Copy link
Contributor Author

In theory somebody can break the reset and change view creation to overwrite existing view (or just fail silently), the test will still pass but the behavior will be wrong. I don't feel too strongly about this either though.

I'll make the change. It makes more sense as a unit test to consider specifically the contract promised by the code under test, rather than trying to play out a scenario from some remote bug report.

@PaulAllanSturm
Copy link
Contributor Author

I've updated the test.

Copy link
Member

@knopp knopp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Copy link
Member

@jonahwilliams jonahwilliams left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jonahwilliams jonahwilliams added the autosubmit Merge PR when tree becomes green via auto submit App label Feb 18, 2025
@auto-submit auto-submit bot added this pull request to the merge queue Feb 19, 2025
Merged via the queue into flutter:master with commit 6ac63dc Feb 19, 2025
175 checks passed
@flutter-dashboard flutter-dashboard bot removed the autosubmit Merge PR when tree becomes green via auto submit App label Feb 19, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 20, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 20, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 20, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 20, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 21, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 21, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 21, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 21, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 21, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 22, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 22, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 22, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 22, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 23, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 23, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 24, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 24, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 24, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 24, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 24, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request May 20, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request May 20, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request May 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a: desktop Running on desktop engine flutter/engine repository. See also e: labels. platform-macos
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants