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

[lanyeeee]

go-webview2/pkg/edge/chromium.go

Lines 242 to 261 in 1cea6fa

	func (e *Chromium) Eval(script string) {
	if e.webview == nil {
	return
	}
	_script, err := windows.UTF16PtrFromString(script)
	if err != nil && !errors.Is(err, windows.ERROR_SUCCESS) {
	e.errorCallback(err)
	}
	_, _, err = e.webview.vtbl.ExecuteScript.Call(
	uintptr(unsafe.Pointer(e.webview)),
	uintptr(unsafe.Pointer(_script)),
	0,
	)
	if err != nil && !errors.Is(err, windows.ERROR_SUCCESS) {
	e.errorCallback(err)
	}
	}

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? MicrosoftEdge/WebView2Feedback#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? MicrosoftEdge/WebView2Feedback#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