[Feature Request] Expose DestroyEnvironment for rapid-fire creation/destruction scenarios #97
Description
Hello Salvador,
First, thank you for this incredible library! We are currently integrating WebView4Delphi into SuperMemo 20 (migrating from legacy TWebBrowser/IE), and we wanted to share a use case that might benefit from a small API change.
The Context:
We use TWebV = class(TWVBrowserBase).
Our application runs a hybrid environment where legacy TWebBrowser (ActiveX) and TWebV (WebView2) coexist on the same form and are switched frequently.
The Issue:
We encountered a critical deadlock during rapid element switching. When a TWebV is destroyed, the underlying msedgewebview2.exe takes ~500ms to release file locks on the UserDataFolder.
If we attempt to create a new TWebV immediately (while the old process is still flushing), the GlobalWebView2Loader remains attached to the "dying" environment. The new instance tries to attach to the locked folder and hangs indefinitely.
The Solution:
We solved this by implementing a "Class Cracker" to access the protected GlobalWebView2Loader.DestroyEnvironment method.
This allows us to:
Manually reset the Global Loader state.
Assign a unique, timestamped UserDataFolder for the new instance.
Successfully initialize the new browser immediately, bypassing the file lock.
The Request:
Could you consider making DestroyEnvironment public (or adding a ResetEnvironment method)? This would allow developers to cleanly handle "Zombie Process" locks during rapid navigation without needing to use cracker patterns to access protected members.
(Diagnosis and solution jointly developed by the SuperMemo Team and Google's Gemini 3.0)