Long string callback will make "Overlapped I/O operation is in progress" panic of v1.0.12

[lanyeeee]

trafficstars

https://github.com/wailsapp/go-webview2/blob/1cea6fa283522b953f44435a08c88da6ff35988b/pkg/edge/chromium.go#L242-L261

Error "Overlapped I/O operation is in progress" occurs if the length of the script parameter in Eval function is relatively long (approximately len(script) >= 9000). The corresponding Windows error code is 997.

Steps to reproduce:

1. Download this project myproject.zip
2. Run wails dev
3. Click the Greet button

Then you will see the error message on the console.

I'm sorry to open a new issue, but I wanted to clarify that the previous issue was closed with the comment that it was fixed in v1.0.12. However, I have tested the latest version and can confirm that the problem still persists in v1.0.12.

[leaanthony]

Thanks for the issue and pr. Do you know it's safe to ignore the error?

Relevant? https://github.com/MicrosoftEdge/WebView2Feedback/issues/4611

[lanyeeee]

Thanks for the issue and pr. Do you know it's safe to ignore the error?

The ERROR_IO_PENDING error comes from go's standard library syscall, not the webview API. I believe ERROR_IO_PENDING should be ignored for the following reasons:

1. Eval is inherently fire-and-forget: The primary purpose of Eval is to execute without concern for the result, which allows us to safely ignore non-critical errors.
2. ERROR_IO_PENDING indicates asynchronous operation: This status simply means that the operation is in progress and will complete later. Ignoring it will not impact the final result.
3. Previous versions ran fine without handled it: In fact, earlier versions did not handle Eval errors at all, and Wails continued to function properly.
4. Overhandling non-critical errors like ERROR_IO_PENDING adds unnecessary complexity: Excessive error handling for such cases introduces unnecessary complexity without tangible benefits.

[lanyeeee]

Relevant? https://github.com/MicrosoftEdge/WebView2Feedback/issues/4611

This issue says the return value is null when executing large scripts. I tested it using the webview->ExecuteScript function in the C++ WebView helloworld project. The behavior of the ExecuteScript function was as expected, large scripts executed successfully without any errors, and the return value was normal.

Additionally, I also tested the ExecuteScript function from webview2-rs (which is the base for Tauri's WebView2). The large scripts executed successfully, with no errors, and the return value was as expected.

This issue seems to occur only within go-webview2, which is indeed quite perplexing. The cause of this issue might be related to the syscall in go's standard library.

[KayFelicities]

Encountered same problem, and it takes me 2 days to find out what cause the panic and this issue.

[cyberxnomad]

May I ask if PR-#13 has resolved the issue?

When I use version 1.0.13, this issue still persists. And I also found an issue with the same problem as mine, but it was marked as 'complete': #16.

[lanyeeee]

May I ask if PR-#13 has resolved the issue?

When I use version 1.0.13, this issue still persists. And I also found an issue with the same problem as mine, but it was marked as 'complete': #16.

It seems that this issue hasn't been completely resolved. #13 only resolved the panic occurs when sending long data from backend to frontend (Go -> JS). However, issue #16 discovered that a panic also occurs when sending long data from frontend to backend (JS -> Go).

~~The good news is that you can back to v1.0.10 until the issue is resolved~~