Fix reported freeze

[helin24]

This is to fix an internal freeze report that close can take a long time to finish.

com.teamdev.jxbrowser.browser.internal.BrowserImpl.close(BrowserImpl.java:779)
com.teamdev.jxbrowser.internal.rpc.UniversalServiceConnection.invoke(UniversalServiceConnection.java:183)
com.teamdev.jxbrowser.internal.rpc.transport.CommonThreadCallExecutor.execute(CommonThreadCallExecutor.java:29)
==> com.teamdev.jxbrowser.internal.rpc.transport.CommonThreadResponseConsumer.await(CommonThreadResponseConsumer.java:49) <==
java.util.concurrent.CountDownLatch.await(Unknown Source)

I don't really have a good way to test (e.g. making this part slow), other than to make sure that opening and closing the tool windows remains okay.

[gemini-code-assist]

Code Review

This pull request addresses a UI freeze during shutdown by moving potentially long-running close() calls for JxBrowser components to a background thread. The changes in EmbeddedBrowser.java and WidgetPreviewPanel.java are appropriate as they occur during project/component disposal, not application exit.

However, the change in EmbeddedBrowserEngine.java for application shutdown is risky. It uses a fire-and-forget background task, which may not complete before the IDE exits, potentially leading to data corruption. I've left a comment with a suggestion to use the Disposable pattern, which is the standard and safer way to handle cleanup during application shutdown in IntelliJ plugins.

[helin24]

/gemini review

[gemini-code-assist]

Code Review

This pull request addresses a potential UI freeze by moving potentially long-running close() operations for the embedded browser to a background thread. The changes in EmbeddedBrowserEngine, EmbeddedBrowser, and WidgetPreviewPanel are consistent in using safeExecuteOnPooledThread to avoid blocking the Event Dispatch Thread (EDT), which is a good practice for IntelliJ plugin development and aligns with the repository's style guide on threading. I have one suggestion to further improve the design by centralizing the asynchronous logic to avoid code duplication.

[helin24]

/gemini review

[gemini-code-assist]

Code Review

This pull request addresses a potential UI freeze by moving the blocking JBrowser.close() calls to a background thread. The changes are well-aligned with IntelliJ Platform's threading best practices. Using Disposable for EmbeddedBrowserEngine is a good architectural improvement. I've pointed out a minor code duplication issue that could be refactored for better maintainability.