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

[andydotxyz]

Can you comment on the state of this @schnoddelbotz ? If you think it is still the right approach then please can you re-base on develop now that v2.8.0 is out? Threading has changed a little and this may be better/worse as a result.

[schnoddelbotz]

Can you comment on the state of this @schnoddelbotz ? If you think it is still the right approach then please can you re-base on develop now that v2.8.0 is out? Threading has changed a little and this may be better/worse as a result.

For my app as well as for Fyne Demo, with Fyne 2.7.x and 2.8.0, the mentioned console errors can be fully silenced by setting the fyneDo Migration to true in FyneApp.toml. As mentioned in fyne-io/demo.fyne.io#23 (comment) ... I don't understand why fyne Demo doesn't use that setting, assuming it has been migrated for a long time now.

Given I didn't run into any freezes or error messages since I enabled the migration, I believe dweymouth may have been right from the start, calling the messages false positives. Admittedly, I furthermore wasn't aware that enabling the migration did not only silence warnings but also change behaviour (by wrapping affected calls).

Accordingly, I'd suggest to close this PR, as it tries to solve a non-issue that can be solved by configuration.

[andydotxyz]

I don't understand why fyne Demo doesn't use that setting, assuming it has been migrated for a long time now.

Thanks for calling that out, I am updating the demo now.

I furthermore wasn't aware that enabling the migration did not only silence warnings but also change behaviour (by wrapping affected calls).

It does not solve it by wrapping - it removes old safeties that the warnings were attempting to flag were being relied upon. If it works great without it then I guess we should close the PR though. However, if the events are in fact firing on different goroutines (I think we assumed that with WASM they could not) then there is still a bug.