-
Notifications
You must be signed in to change notification settings - Fork 137
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
No more handle exceptions with the Edge browser #1013
Comments
See #339 |
I am sorry that Edge instantiation does still not work properly. We did not have issues in productive usage recently, but we do not use it intensively either (usually only one instance). Some remarks on this:
I could image that the problem you describe, @vogella, is related to the one that can be seen in the tests. Lines 212 to 247 in 2cdfd97
From my understanding, the OS event processing is supposed to trigger the callback setting the results ( ppv /phr ). However, the callAndWait performs a release on the callback even before doing the event processing, so maybe the problem is something pretty simple like an interface pointer being released too early.Lines 224 to 227 in 2cdfd97
|
…ipse-platform#1013 Instead of always showing a "no more handles" error, with this change an error due to invalid thread access is explicitly logged as such. Contributes to eclipse-platform#1013
@vogella can you share which kind of error code is printed? I.e., there should be a message like |
…ipse-platform#1013 The handle to a newly instantiated Edge browser is provided via a callback. This callback may be either be invoked synchronously when creating a WebView2 controller (happens on first creation of an Edge browser instance in an application) or asynchronously via a processed OS event (from second creation of an Edge browser instance onwards). The callback is currently released before the OS events are processed, which may cause issues when instantiating more than one Edge browser in a single application. With this change, the callback is only released when it is not required and may not be called anymore. A test instantiating multiple (Edge) browsers in a single application is added to ensure that the asynchronous callback invocation is executed in a test. Contributes to eclipse-platform#1013
…ipse-platform#1013 Instead of always showing a "no more handles" error, with this change an error due to invalid thread access is explicitly logged as such. Contributes to eclipse-platform#1013
…ipse-platform#1013 The handle to a newly instantiated Edge browser is provided via a callback. This callback may be either be invoked synchronously when creating a WebView2 controller (happens on first creation of an Edge browser instance in an application) or asynchronously via a processed OS event (from second creation of an Edge browser instance onwards). The callback is currently released before the OS events are processed, which may cause issues when instantiating more than one Edge browser in a single application. With this change, the callback is only released when it is not required and may not be called anymore. A test instantiating multiple (Edge) browsers in a single application is added to ensure that the asynchronous callback invocation is executed in a test. Contributes to eclipse-platform#1013
We see two errors: [0x8007139f] happens more frequently. |
Instead of always showing a "no more handles" error, with this change an error due to invalid thread access is explicitly logged as such. Contributes to #1013
The handle to a newly instantiated Edge browser is provided via a callback. This callback may be either be invoked synchronously when creating a WebView2 controller (happens on first creation of an Edge browser instance in an application) or asynchronously via a processed OS event (from second creation of an Edge browser instance onwards). The callback is currently released before the OS events are processed, which may cause issues when instantiating more than one Edge browser in a single application. With this change, the callback is only released when it is not required and may not be called anymore. A test instantiating multiple (Edge) browsers in a single application is added to ensure that the asynchronous callback invocation is executed in a test. Contributes to #1013
Thanks for sharing! Some documentation I found (including the Microsoft documentation) states the following:
The question is what kind of concurrent operation or incorrect state that is. One thing I could imagine is the access to a shared data directory: all Edge instances within (Eclipse) applications that have the same application name share the same data directory with the following path: eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/win32/org/eclipse/swt/widgets/Display.java Line 2851 in 44432b2
This will be something like C:\Users\...\AppData\Local\Eclipse .
@vogella is it possible for you to set the system property |
@HeikoKlare thanks for the information, we will try the org.eclipse.swt.browser.EdgeDataDir setting and I will report back if that solves the issue. |
The current implementation of the Edge browser creates a WebView2Environment on first creation of an WebView2 / Edge browser instance. On every further creation of a WebView2 instance, this environment is used. In case the WebView2 instance is created for a different display, i.e., within a different thread, the instantiation fails as the WebView2Environment has been created in a different thread. To support the creation of WebView2 instances in different displays, this change replaces the static WebView2Environment with one environment for every display. The WebView2 instances are created for the environment belonging to the display for which the current instantiation is requested. An according regression test is added. Contributes to eclipse-platform#1013
The current implementation of the Edge browser creates a WebView2Environment on first creation of an WebView2 / Edge browser instance. On every further creation of a WebView2 instance, this environment is used. In case the WebView2 instance is created for a different display, i.e., within a different thread, the instantiation fails as the WebView2Environment has been created in a different thread. To support the creation of WebView2 instances in different displays, this change replaces the static WebView2Environment with one environment for every display. The WebView2 instances are created for the environment belonging to the display for which the current instantiation is requested. An according regression test is added. Contributes to eclipse-platform#1013
JVM shutdown hook, via
works fine now (not sure what was wrong before). And we currently do not see the no more handlers exception. Thanks @HeikoKlare |
Good to hear that setting the data directory may solve/circumenvent the problem. Still this is quite interesting as meanwhile I took a look into Microsoft's documentation which states that in case you configure multiple WebView2Environments equally, they should be able to share a data directory: https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/process-model?tabs=csharp#multiple-environment-objects Anyway, I would expect that different RCP applications do not share browser data by default. I would rather expect an RCP application to place the browser data directory within its workspace folder. So maybe in case the user does not set a custom data directory, an RCP application should explicitly do so?
Might be that this is a race condition, since the WebView2Environment handle is also released via a display dispose listener: Lines 349 to 352 in 44432b2
|
The current implementation of the Edge browser creates a WebView2Environment on first creation of an WebView2 / Edge browser instance. On every further creation of a WebView2 instance, this environment is used. In case the WebView2 instance is created for a different display, i.e., within a different thread, the instantiation fails as the WebView2Environment has been created in a different thread. To support the creation of WebView2 instances in different displays, this change replaces the static WebView2Environment with one environment for every display. The WebView2 instances are created for the environment belonging to the display for which the current instantiation is requested. An according regression test is added. Contributes to eclipse-platform#1013
The current implementation of the Edge browser creates a WebView2Environment on first creation of an WebView2 / Edge browser instance. On every further creation of a WebView2 instance, this environment is used. In case the WebView2 instance is created for a different display, i.e., within a different thread, the instantiation fails as the WebView2Environment has been created in a different thread. To support the creation of WebView2 instances in different displays, this change replaces the static WebView2Environment with one environment for every display. The WebView2 instances are created for the environment belonging to the display for which the current instantiation is requested. An according regression test is added. Contributes to eclipse-platform#1013
The current implementation of the Edge browser creates a WebView2Environment on first creation of an WebView2 / Edge browser instance. On every further creation of a WebView2 instance, this environment is used. In case the WebView2 instance is created for a different display, i.e., within a different thread, the instantiation fails as the WebView2Environment has been created in a different thread. To support the creation of WebView2 instances in different displays, this change replaces the static WebView2Environment with one environment for every display. The WebView2 instances are created for the environment belonging to the display for which the current instantiation is requested. An according regression test is added. Contributes to #1013
Thanks @HeikoKlare for your work. We tested your changes via the i-build from yesterday and it seems to solve our errors event without the edge data setting in most cases. We tested: Starting multiple production RCP applications in parallel with and without the edge data directory set. It still gives the error: |
Thanks for the follow-up information! To me, it still seems to make sense to have the data folder either placed in the installation folder or even within the workspace (metadata) folder:
Then applications / workspaces are isolated properly. But it also feels a little strange to integrate such specific behavior into the general framework and maybe that should be something each application decides on its own. Then we could only think about adding it to the IDEApplication. |
@HeikoKlare using the installfolder is maybe not a good idea as one can still start multiple eclipse from the same install but different workspaces. Also the install location might be read-only. |
That's true. I also think that the workspace directory makes much more sense (semantically). Technically, it should be possible that multiple Eclipse instances started from the same installation use the same, shared data folder (according to the WebView2 documentation). But even if that worked properly, you are right that the install folder might be read-only and then you need some fallback anyway. |
just to share ours stuff that we get when enabling the Edge browser:
that is what we get all the time when we use a tooltip that uses the browser Then i tried to debug it a bit, and that got me to a very surprising behavior that is the Edge class if i place a break point at 361, when it hits an i press resume.. |
Error code Can you please post the environment (OS version, WebView2 version) on which the problem occurs? Doing a web search for that error code in combination with WebView2 gives several results over the last years, e.g., MicrosoftEdge/WebView2Feedback#3097 |
With this contribution, Edge browser uses the workspace directory for the userdata directory for the separation of the usage of userdata directory per workspace by the webview2Environment. contributes to eclipse-platform#1013
This contributes to adding the workspace address to the display data on the initilization of the workbench. This contribution allows further SWT components to utilize this information. Contributes to eclipse-platform/eclipse.platform.swt#1013
With this contribution, Edge browser uses the workspace directory for the userdata directory for the separation of the usage of userdata directory per workspace by the webview2Environment. contributes to eclipse-platform#1013
This contributes to adding the workspace address to the display data on the initilization of the workbench. This contribution allows further SWT components to utilize this information. Contributes to eclipse-platform/eclipse.platform.swt#1013
With this contribution, Edge browser uses the workspace directory for the userdata directory for the separation of the usage of userdata directory per workspace by the webview2Environment. contributes to eclipse-platform#1013
With this contribution, a custom userdata directory can provided to Edge browser via its Display for the separation of the usage of userdata directory per application by the webview2Environment. contributes to eclipse-platform#1013
With this contribution, a custom userdata directory can provided to Edge browser via its Display for the separation of the usage of userdata directory per application by the webview2Environment. contributes to eclipse-platform#1013
With this contribution, a custom userdata directory can provided to Edge browser via its Display for the separation of the usage of userdata directory per application by the webview2Environment. contributes to eclipse-platform#1013
This contributes to adding the workspace address to the display data on the initilization of the workbench. This contribution allows further SWT components to utilize this information. Contributes to eclipse-platform/eclipse.platform.swt#1013
With this contribution, a custom userdata directory can provided to Edge browser via its Display for the separation of the usage of userdata directory per application by the webview2Environment. contributes to eclipse-platform#1013
With this contribution, a custom userdata directory can provided to Edge browser via its Display for the separation of the usage of userdata directory per application by the webview2Environment. contributes to eclipse-platform#1013
With this contribution, a custom userdata directory can provided to Edge browser via its Display for the separation of the usage of userdata directory per application by the webview2Environment. contributes to #1013
This contributes to adding the workspace address to the display data on workbench initialization as the data directory used by Edge browser. Contributes to eclipse-platform/eclipse.platform.swt#1013
This contributes to adding the workspace address to the display data on workbench initialization as the data directory used by Edge browser. Contributes to eclipse-platform/eclipse.platform.swt#1013
Re-opening this as we still need eclipse-platform/eclipse.platform.ui#2434 to be merged for this to make a difference. |
Thanks for reopening! Sometimes, I am confused why issues become auto-closed, since there was no "fixes", "closes" or the like keyword in the PR/commit due to which this issue has been closed. |
Thanks! I missed that one. |
This contributes to adding the workspace address to the display data on workbench initialization as the data directory used by Edge browser. Contributes to eclipse-platform/eclipse.platform.swt#1013
This contributes to adding the workspace address to the display data on workbench initialization as the data directory used by Edge browser. Contributes to eclipse-platform/eclipse.platform.swt#1013
We can close this issue now. It has been fixed by #1548. |
All causes of "no more handles" in Edge that we know of have been fixed. Thus we close this issue for now. In case anyone experiences further unexpected "no more handles" errors, please reopen this issue or create a new one. |
With this contribution, a custom userdata directory can provided to Edge browser via its Display for the separation of the usage of userdata directory per application by the webview2Environment. contributes to eclipse-platform#1013
Using the Edge browser on Windows still results in a the no more handlers exception even after the commit ed8f821 from @HeikoKlare
Before the commit, the error was in Edge.java:343, now it occurs in Edge.java:362.
https://github.com/eclipse-platform/eclipse.platform.swt/blob/master/bundles/org.eclipse.swt/Eclipse%20SWT%20Browser/win32/org/eclipse/swt/browser/Edge.java#L362C1-L363C1
It seems to happen if the user starts multiple time the same application in different workspaces. I will try to provide a test case to reproduce.
The text was updated successfully, but these errors were encountered: