-
Notifications
You must be signed in to change notification settings - Fork 160
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
Edge: Freeze in Browser#evaluate() if evaluated script calls into SWT #1771
Comments
Thank you for this report, @sratz! We are currently investigating potential reasons for Edge blocking the UI thread (according to eclipse-platform/eclipse.platform.ui#2734) starting with this PR: I also pointed to the calls to In my opinion, we could/should replace all the calls to |
I've created a draft PR with the idea for the improvement: |
…ipse-platform#1771 Before recent improvements of the Edge implementation, it was possible that a browser instance was disposed during WebView initialization, which made the initialization fail exceptionally. This has been worked around by not processing all kinds of asynchronously scheduled events (like a disposal) while waiting for WebView initialization but only those being processes by the OS event queue. This was still necessary to process the OS callbacks for WebView initialization and other operations. In some cases, this may lead to an Edge browser instance blocking the UI thread, as some asynchronously scheduled tasks need to be processed but are not. In addition, enhancements of the Edge implementation made the initialization happen asynchronously anyway, such that the browser instantiation itself cannot throw an error anymore, but the asynchronously happening initialization is now capable of processing asynchronous browser disposals. This change simplifies the event processing inside Edge to not only process the next OS message but to just ordinarily spin the event loop. This reduces the risk of operations executed on an Edge browser to block execution. eclipse-platform#1771
…ipse-platform#1771 Before recent improvements of the Edge implementation, it was possible that a browser instance was disposed during WebView initialization, which made the initialization fail exceptionally. This has been worked around by not processing all kinds of asynchronously scheduled events (like a disposal) while waiting for WebView initialization but only those being processes by the OS event queue. This was still necessary to process the OS callbacks for WebView initialization and other operations. In some cases, this may lead to an Edge browser instance blocking the UI thread, as some asynchronously scheduled tasks need to be processed but are not. In addition, enhancements of the Edge implementation made the initialization happen asynchronously anyway, such that the browser instantiation itself cannot throw an error anymore, but the asynchronously happening initialization is now capable of processing asynchronous browser disposals. This change simplifies the event processing inside Edge to not only process the next OS message but to just ordinarily spin the event loop. This reduces the risk of operations executed on an Edge browser to block execution. eclipse-platform#1771
…ipse-platform#1771 Before recent improvements of the Edge implementation, it was possible that a browser instance was disposed during WebView initialization, which made the initialization fail exceptionally. This has been worked around by not processing all kinds of asynchronously scheduled events (like a disposal) while waiting for WebView initialization but only those being processes by the OS event queue. This was still necessary to process the OS callbacks for WebView initialization and other operations. In some cases, this may lead to an Edge browser instance blocking the UI thread, as some asynchronously scheduled tasks need to be processed but are not. In addition, enhancements of the Edge implementation made the initialization happen asynchronously anyway, such that the browser instantiation itself cannot throw an error anymore, but the asynchronously happening initialization is now capable of processing asynchronous browser disposals. This change simplifies the event processing inside Edge to not only process the next OS message but to just ordinarily spin the event loop. This reduces the risk of operations executed on an Edge browser to block execution. eclipse-platform#1771
…ipse-platform#1771 Before recent improvements of the Edge implementation, it was possible that a browser instance was disposed during WebView initialization, which made the initialization fail exceptionally. This has been worked around by not processing all kinds of asynchronously scheduled events (like a disposal) while waiting for WebView initialization but only those being processes by the OS event queue. This was still necessary to process the OS callbacks for WebView initialization and other operations. In some cases, this may lead to an Edge browser instance blocking the UI thread, as some asynchronously scheduled tasks need to be processed but are not. In addition, enhancements of the Edge implementation made the initialization happen asynchronously anyway, such that the browser instantiation itself cannot throw an error anymore, but the asynchronously happening initialization is now capable of processing asynchronous browser disposals. This change simplifies the event processing inside Edge to not only process the next OS message but to just ordinarily spin the event loop. This reduces the risk of operations executed on an Edge browser to block execution. eclipse-platform#1771
@sratz @HeikoKlare I think the reproducer violates the basic contract of evaluate that is:
As you invoke the evaluate synchronously with construction but access So that it works here is more maybe the bug, the browser should most likley fire the event of document load inside an asnyc exec and your code should look like this:
I can't really think of any (non deadlock prone) way to support async javascript loading and synchronous instantiation of a browsers document, and this is also the reason why this will never happen in a real web application and |
Some more insights on the underlying cause of this: when opening a new window, the OS callback does not directly process this creation but, again, creates an async task to do it: Lines 1249 to 1294 in 8f5e8fd
Since our This is the reason why spinning the event loop "solved" the problem, as it will execute that asynchronous task. Simply performing the execution of that callback synchronously without creating an async task does not work either, as then other use cases (specified as tests) will get stuck. |
As mentioned here: I think it is not appropriate to "join" a future unconditionally on the event thread (in any case) without special considerations/handling. |
I was preparing to create an issue when I found this one. I think this is the same problem, if not please tell me and I will open a new one. Having the following demo application, pressing the button the
For testing purpose I use a simple In Eclipse 2024-09 the following exception was thrown, in 2024-12 and the current integration build 3.16.200.v20250224-0600 the application just freezes.
|
This commit cotributes to executing the registered listeners of Edge browser on Browser callbacks in a asynchronous fashion making sure no WebView related task is executed while a WebView callback is already executing making sure there's no deadlock. contributes to eclipse-platform#1771 and eclipse-platform#1919
This commit cotributes to executing the registered listeners of Edge browser on Browser callbacks in a asynchronous fashion making sure no WebView related task is executed while a WebView callback is already executing making sure there's no deadlock. contributes to eclipse-platform#1771 and eclipse-platform#1919
This commit cotributes to executing the registered listeners of Edge browser on Browser callbacks in a asynchronous fashion making sure no WebView related task is executed while a WebView callback is already executing making sure there's no deadlock. contributes to eclipse-platform#1771 and eclipse-platform#1919
This commit cotributes to executing the registered listeners of Edge browser on Browser callbacks in a asynchronous fashion making sure no WebView related task is executed while a WebView callback is already executing making sure there's no deadlock. contributes to eclipse-platform#1771 and eclipse-platform#1919
This commit cotributes to executing the registered listeners of Edge browser on Browser callbacks in a asynchronous fashion making sure no WebView related task is executed while a WebView callback is already executing making sure there's no deadlock. contributes to eclipse-platform#1771 and eclipse-platform#1919
This commit cotributes to executing the registered listeners of Edge browser on Browser callbacks in a asynchronous fashion making sure no WebView related task is executed while a WebView callback is already executing making sure there's no deadlock. contributes to eclipse-platform#1771 and eclipse-platform#1919
This commit cotributes to replicating the behaviour of Edge:evaluate as it is in WebKit - it must not wait for the execution of script to obtain the result, in case evaluate is called inside a WebView callback. This commit also makes sure that OpenWindowListeners are execute synchronously or asynchronously depending on if the handleNewWindowRequested is called from the evaluate script. Moreover, this enables all the tests which were failing because of Edge:evaluate limitations. contributes to eclipse-platform#1771 and eclipse-platform#1919
This commit cotributes to replicating the behaviour of Edge:evaluate as it is in WebKit - it must not wait for the execution of script to obtain the result, in case evaluate is called inside a WebView callback. This commit also makes sure that OpenWindowListeners are execute synchronously or asynchronously depending on if the handleNewWindowRequested is called from the evaluate script. Moreover, this enables all the tests which were failing because of Edge:evaluate limitations. contributes to eclipse-platform#1771 and eclipse-platform#1919
This commit cotributes to replicating the behaviour of Edge:evaluate as it is in WebKit - it must not wait for the execution of script to obtain the result, in case evaluate is called inside a WebView callback. This commit also makes sure that OpenWindowListeners are execute synchronously or asynchronously depending on if the handleNewWindowRequested is called from the evaluate script. Moreover, this enables all the tests which were failing because of Edge:evaluate limitations. contributes to eclipse-platform#1771 and eclipse-platform#1919
This commit cotributes to replicating the behaviour of Edge:evaluate as it is in WebKit - it must not wait for the execution of script to obtain the result, in case evaluate is called inside a WebView callback. This commit also makes sure that OpenWindowListeners are execute synchronously or asynchronously depending on if the handleNewWindowRequested is called from the evaluate script. Moreover, this enables all the tests which were failing because of Edge:evaluate limitations. contributes to eclipse-platform#1771 and eclipse-platform#1919
This commit cotributes to replicating the behaviour of Edge:evaluate as it is in WebKit - it must not wait for the execution of script to obtain the result, in case evaluate is called inside a WebView callback. This commit also makes sure that OpenWindowListeners are execute synchronously or asynchronously depending on if the handleNewWindowRequested is called from the evaluate script. Moreover, this enables all the tests which were failing because of Edge:evaluate limitations. contributes to eclipse-platform#1771 and eclipse-platform#1919
This commit cotributes to replicating the behaviour of Edge:evaluate as it is in WebKit - it must not wait for the execution of script to obtain the result, in case evaluate is called inside a WebView callback. This commit also makes sure that OpenWindowListeners are execute synchronously or asynchronously depending on if the handleNewWindowRequested is called from the evaluate script. Moreover, this enables all the tests which were failing because of Edge:evaluate limitations. contributes to #1771 and #1919
Describe the bug
With Edge, when using
browser.evaluate(script)
andscript
somehow causing a callback into SWT, theevaluate()
freezes / hangs in 100% CPU.To Reproduce
Expected behavior
Test succeeds with IE and Edge.
Actual behavior
Test hangs with Edge, succeeds with IE.
Stack trace shows:
Environment:
Additional context
This is a side-effect of #660, where inside
Edge.callAndWait()
if (!display.readAndDispatch()) display.sleep();
was replaced with
processNextOSMessage();
.@HeikoKlare:
PR #660 suggest that this was to avoid a out-of-handles during initialization, i.e. inside
createEnvironment()
, but it also affects theevaluate()
call negatively.Do you think it would be reasonable to keep using
display.readAndDispatch()
in the latter?The text was updated successfully, but these errors were encountered: