[window_proc_delegate] fix crash on multi engine

[boyan01]

No description provided.

[gemini-code-assist]

Summary of Changes

Hello @boyan01, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request delivers a crucial fix for the window_proc_delegate plugin, specifically addressing crashes that arise in multi-engine Flutter desktop applications. The core problem stemmed from the plugin's inability to differentiate between multiple Flutter engine instances when handling Windows messages. The solution involves a comprehensive refactoring of the native Windows code to correctly map WindowProc delegate callbacks to their respective engine IDs, ensuring that each window's messages are processed by the correct Dart isolate. The example application has also been updated to demonstrate this multi-window capability, providing a clear validation of the fix.

Highlights

• Multi-Engine Crash Fix: Resolved a critical crash in the window_proc_delegate plugin that occurred when used in applications with multiple Flutter engines (e.g., multiple windows). The plugin now correctly associates WindowProc delegate callbacks with their specific Flutter engine IDs.
• Engine ID Management: Implemented a mechanism to register and manage WindowProc callbacks per Flutter engine ID on the native Windows side. This ensures that window messages are routed to the correct Dart isolate, preventing conflicts and crashes in multi-window scenarios.
• Example App Enhancement: Updated the example application to demonstrate multi-window functionality by integrating the desktop_multi_window package. A new button allows users to create child windows, showcasing the stability of the window_proc_delegate plugin in such environments.
• Native Code Refactoring: Refactored the native C++ code for the window_proc_delegate plugin to use global maps and mutexes for thread-safe management of plugin instances and their associated Dart callbacks across different engine IDs. This includes handling pending callbacks for plugins not yet fully initialized.
• Dart API for Engine Initialization: Introduced an ensureInitializeEngineId method in the Dart API, allowing explicit registration of the current engine's ID with the native plugin. This can be called early in the application lifecycle to ensure proper setup.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a significant and well-executed refactoring of the native Windows plugin to properly support multiple Flutter engines, addressing a crash issue in multi-window scenarios. The new architecture, which manages plugin instances and callbacks on a per-engine basis, is robust and correctly handles the complexities of a multi-engine environment. The accompanying changes in the Dart layer and the example application are appropriate and help validate the fix. I have one high-severity suggestion in the Dart code to improve the error handling and robustness of the engine initialization logic, preventing potential unhandled exceptions. Overall, this is an excellent and crucial improvement for the plugin.

[gemini-code-assist]

In ensureInitializeEngineId, the _engineIdInitialized flag is set to true before the asynchronous invokeMethod call. If invokeMethod fails, the flag will remain true, preventing any future attempts to initialize the engine ID. Additionally, the rethrow in the catch block will cause an unhandled asynchronous error when ensureInitializeEngineId is called in a fire-and-forget manner from the initialize function, which could crash the application.

To make this more robust, I suggest setting _engineIdInitialized only after the method call succeeds. Also, since the call from initialize is fire-and-forget, rethrowing the error is not desirable. Removing the rethrow will prevent a potential crash from an unhandled exception.

  final int engineId = PlatformDispatcher.instance.engineId!;
  try {
    await _channel.invokeMethod('setEngineId', engineId);
    _engineIdInitialized = true;
  } catch (e) {
    debugPrint('Failed to set engine ID: $e');
  }