wasm: fix errors reported in console by wrapping given functions in fyne.Do

[schnoddelbotz]

Description:

The current fyne Demo on https://demo.fyne.io/ (2.6.0) as well as current https://github.com/fyne-io/demo throw errors in browser console, indicating that some function calls in internal/driver/glfw/window_wasm.go should be wrapped in Fyne.Do(), e.g.

*** Error in Fyne call thread, this should have been called in fyne.Do[AndWait] ***
   From: /var/home/jacob/go/pkg/mod/fyne.io/fyne/v2@v2.6.0/internal/driver/glfw/window_wasm.go:474

The error can be triggered by going to Widget->Entry and typing some characters into one of the text inputs.

The change in this PR just implements the fix indicated by the error message and successfully silences any corresponding error messages for me.

Checklist:

• Tests included.
• Lint and formatter run with no errors.
• Tests all pass.

[dweymouth]

I am not that familiar with the wasm runtime but I think it's more likely that the main thread detection doesn't work on wasm (and therefore that these warnings are false positives) then that there's an actual threading issue. Especially since I'm pretty sure wasm is single-threaded

[andydotxyz]

Elsewhere in this file we use runOnMain. Does it work if that fix is in place instead?
I think the change could be logical.
As @dweymouth says we may need to look at how the WASM GLFW works - but this seems like a good intermediate change - if we can match the pattern used elsewhere.

[schnoddelbotz]

Thank you both for looking into this. I tried using runOnMain in the latest commit.
Unfortunately, it seems to worsen things: While both variants silence the warnings, using runOnMain seems to introduce another timing issue/deadlock when opening the app again in a new tab :-(

See attached video for to see both commits in comparison - the non-blinking cursor indicates a crash.
Difference in builds go.mod:

# using fyne.Do
replace fyne.io/fyne/v2 => github.com/schnoddelbotz/fyne/v2 v2.7.3-0.20260209121734-836b6dab1482

# using runOnMain
replace fyne.io/fyne/v2 => github.com/schnoddelbotz/fyne/v2 v2.7.3-0.20260210231647-50ac1c4b641a

Unsure where to go from here - feel free to just close the PR and let me know in case I should file an issue to address the root cause; might have been the right thing to do in the first place. Sorry for believing it was so simple to fix.

fyne-do-vs-run-on-main.mp4

[schnoddelbotz]

I took another look at this and parked resulting changes in another branch:
develop...schnoddelbotz:fyne:wasm-console-errors

Findings:

• Using fyne.Do on charInput and focused seem to be sufficient to avoid any errors/crashes; without it or when using runOnMain, it would often run into aforementioned deadlock.
• The demo.fyne.io as well as my tiny wasm app would crash whenever I triggered a dark/light-mode switch.
  The branch above also "solves" that issue for me, but the solution is an obvious hack. I simply found no other way to avoid crashes whenever DeleteTexture was called. This would probably be another issue to report; I just wanted to note it here, as it negatively affects the public-facing demo, too.
• Looking at https://stackoverflow.com/questions/67575197/how-are-go-channels-and-goroutines-translated-to-webassembly makes me believe that fyne.Do could be needed despite wasm being single-threaded; accordingly, I wrapped the theme switch operation in fyne.Do (and it seems to be required to avoid the crash).

[andydotxyz]

While both variants silence the warnings, using runOnMain seems to introduce another timing issue/deadlock when opening the app again in a new tab :-(

If runOnMain can deadlock then it means fyne.Do was not the right answer after all - it was just hiding deeper,

The demo.fyne.io as well as my tiny wasm app would crash whenever I triggered a dark/light-mode switch.

This is a separate issue I think - fyne-io/demo#4