-
Notifications
You must be signed in to change notification settings - Fork 164
Edge: Operation timed out on evaluate() #1919
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
Comments
Hi colleagues
|
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
Add a test to it. Fixes eclipse-platform#1919
Add a test to it. The test is currently deactivated for Linux (see eclipse-platform#2021) Fixes eclipse-platform#1919
@yuriypalych / @fipro78 this should be fixed for Windows (Edge and IE) by #2019 . Could any of you guys kindly check on Linux and see if the same error is reproducible? I noticed while adding a test that the test fails on Linux (see #2021 ) so it might be that this very issue affects Linux too. I just haven't found the time to confirm it yet so any help would be appreciated. |
Many thanks for the info, @fedejeanne
Unfortunately I use Windows only, cannot check. |
Describe the bug
I started an application that contains a
RichTextEditor
and get an error on startup:Might be a duplicate of #1771
To Reproduce
org.eclipse.nebula.widgets.richtext.example
org.eclipse.nebula.widgets.richtext.example.RichTextEditorExample
main
methodNote:
You first need to locally fix
org.eclipse.nebula.widgets.richtext.RichTextEditor#setBounds(int, int, int , int)
and replace line 757 withThe call stack in SWT Control was changed which now leads to a StackOverflowError as reported in EclipseNebula/nebula#631. While trying to fix this, I came across this issue. I need to find a way to verify if the fix works before I actually can push it.
Expected behavior
A shell should open and show the RichTextEditor.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment:
Additional OS info (e.g. OS version, Linux Desktop, etc)
JRE/JDK version
Version since
Eclipse or SWT version since when the behavior is seen [e.g. 4.23]
Workaround (or) Additional context
Add any other context about the problem here.
Any known workarounds for the problem?
The text was updated successfully, but these errors were encountered: