/cc @neelance

I think this should be handled in wasmbrowsertest rather than inside the run function. I checked the code and the error paths can be improved to show a better error for cases like these.

If you use the node runner, then you don't get an error like this. So I think it falls on wasmbrowsertest to handle this case.

I saw this before I ever used wasmbrowsertest, when I was messing around with index.html to switch it from clicking a 'Run' button to starting on window load / from the instantiatestreaming callback. I'll have to modify it again when I start messing with service workers in earnest.

My point is people who actually use index.html in a real application aren't going to have a run button and will definitely modify index.html's code which calls into wasm_exec.js. Once they do that their index.html is going to start to look nothing like the current index.html. Presumably the plan is for such apps to continue to use wasm_exec.js unmodified to make it easier to take changes from the Go repo. When such apps do so, I think it's reasonable to expect wasm_exec.js to throw exceptions when you use its public APIs incorrectly instead of throwing errors which require devs to read and understand wasm_exec.js's code.

Please keep in mind that wasm_exec.js's API is not fully "public" until js/wasm is stable. Right now it is meant for early adopters and can change at any time. However, I agree with you that a better error message can ease this pitfall at almost zero cost. I'll add it in the next release cycle.

Once they do that their index.html is going to start to look nothing like the current index.html.

Ah yes, that's a good point.

Change https://golang.org/cl/266117 mentions this issue: misc/wasm: check type of argument to Go.run