Skip to content
This repository was archived by the owner on Feb 25, 2025. It is now read-only.

Conversation

@yaakovschectman
Copy link
Contributor

FlutterWindowsView owns both the FlutterWindowsEngine and WindowBindingHandler as 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

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I read the Tree Hygiene wiki page, which explains my responsibilities.
  • I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
  • I listed at least one issue that this PR fixes in the description above.
  • I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
  • I updated/added relevant documentation (doc comments with ///).
  • I signed the CLA.
  • All existing and new tests are passing.

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

}

FlutterWindowsView::~FlutterWindowsView() {
DestroyRenderSurface();
Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What are you considering when the state is torn down? At the start of the destructor being called?

Copy link
Member

Choose a reason for hiding this comment

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

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 yaakovschectman marked this pull request as ready for review February 23, 2023 22:10
Copy link
Member

@loic-sharma loic-sharma left a comment

Choose a reason for hiding this comment

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

Nice work!

Copy link
Member

@scutlight scutlight left a comment

Choose a reason for hiding this comment

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

LGTM!

@yaakovschectman yaakovschectman merged commit d2d00be into flutter:main Feb 24, 2023
@yaakovschectman yaakovschectman deleted the unregister_windows_view branch February 24, 2023 19:35
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
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"
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

3 participants