I got some more error at the bottom while trying to reproduce this -

(index):24 Uncaught (in promise) RangeError: WebAssembly Instantiation: Out of memory: wasm memory
async function (async)
run @ (index):22
onclick @ (index):29
wasm_loader.js:305 Uncaught (in promise) Error: bad callback: Go program has already exited
    at _values (wasm_loader.js:305)
    at eval (eval at syscall/js.valueCall (wasm_loader.js:222), <anonymous>:5:4)

/cc @neelance , @johanbrandhorst

This is a nonsensical example, no? Add a waitgroup or something to monitor the progress of the callback before exiting.

I've investigated this a bit more, and indeed, I think there is a problem. Modifying the code like so still exhibits the same problem:

package main

import (
	"fmt"
	"net/http"
	"syscall/js"
)

func main() {
	var cb js.Callback
	done := make(chan struct{})
	cb = js.NewCallback(func(args []js.Value) {
		fmt.Println("Clicked")
		resp, err := http.Get("/")
		fmt.Println(resp, err)
		close(done)
	})
	js.Global.Get("document").Call("getElementById", "btn").Call("addEventListener", "click", cb)
	<-done
}

The problem is that, indeed, all goroutines are asleep (while waiting for Fetch I/O). I'm not sure how to solve this so will defer to @neelance.

The problem is that you are blocking the callback loop. New calls to callbacks (like the HTTP response) can not be processed while some other callback handler (like the click handler) have not returned. You need to explicitly start a new goroutine:

package main

import (
	"fmt"
	"net/http"
	"syscall/js"
)

func main() {
	var cb js.Callback
	done := make(chan struct{})
	cb = js.NewCallback(func(args []js.Value) {
		go func() {
			fmt.Println("Clicked")
			resp, err := http.Get("/")
			fmt.Println(resp, err)
			close(done)
		}()
	})
	js.Global.Get("document").Call("getElementById", "btn").Call("addEventListener", "click", cb)
	<-done
}

Ah I see. Makes sense now. It was not immediately apparent that the callback loop is being blocked.

I should have read the documentation first - https://tip.golang.org/pkg/syscall/js/?GOOS=js&GOARCH=wasm#NewCallback

This execution happens asynchronously on a special goroutine that handles all callbacks and preserves the order in which the callbacks got called. As a consequence, if one callback blocks this goroutine, other callbacks will not be processed. A blocking callback should therefore explicitly start a new goroutine.

@neelance - Feel free to close the bug if you don't think there is anything else to be done.

Can't close the bug since it is not assigned to me.

Thank you for comments.
I understand about js.Callback behavior by your explanation.
But I think it is not good that users of a package should mind whether the package is using js.Callback or not.

I understand. Unfortunately this is working as intended and documented explicitly. So I don't think much can be done except educate the users.

Maybe in future, this behavior can change. But until then, it is unlikely we will be able to do anything.

The only idea that I have to improve this is to rename NewCallback to NewOrderedCallback and then have NewCallback create a new goroutine implicitly. Is this something we should do?

Kinda goes against the set of callbacks we have - NewCallback for any generic callback and NewEventCallback for events. NewOrderedCallback introduces a different category of a callback than what we have. That's my thinking as an end user.

I was wondering how the order of callbacks matters.

There are several JS APIs that depend on it. Usually JS devs (me included when writing JS) don't spend much thought on this since it is "simply" a property of the execution model, so generally assumed (JS devs also don't think about issues due to preemption, because there is none). See https://go-review.googlesource.com/c/go/+/114197/6/src/syscall/js/callback.go#52 and https://go-review.googlesource.com/c/go/+/114197/8/src/syscall/js/callback.go#57.

I probably not understand what is problem. Can we add function that wait all callbacks?

var (
	callbacks = map[Callback]chan struct{}{}
	mu sync.Mutex
)

func NewCallback(f func(args []Value)) Callback {
	// do something...
	return func(args []Value) {
		ch := make(chan struct{})
		mu.Lock()
		callbacks[f] = ch
		mu.Unlock()
		go func() {
			f(args)

			close(ch)
			mu.Lock()
			delete(callbacks, ch)
			mu.Unlock()
		}()
	}
}

func Wait() {
	for {
		// wait all callbacks
	}
}

@mattn Now I don't get what you are saying...

@neelance I mean that I wonder that Go really can't solve this. For example, I don't make sure, is it possible to make channel/goroutine in Go instead of user code?