@neelance, I think you have the most context here. Let me know if there's any way I can help!

Here's another example of a program that actually uses the listener instead of just printing out ln.Addr():

package main

import (
	"fmt"
	"io/ioutil"
	"net"
)

func main() {
	ln, err := net.Listen("tcp", "127.0.0.1:8080")
	if err != nil {
		panic(err)
	}
	defer ln.Close()
	fmt.Println(ln.Addr())

	go func() {
		conn, err := net.Dial("tcp", "127.0.0.1:8080")
		if err != nil {
			panic(err)
		}
		defer conn.Close()
		if _, err := conn.Write([]byte("Hello!")); err != nil {
			panic(err)
		}
	}()

	fmt.Println("Waiting for new connections...")
	conn, err := ln.Accept()
	if err != nil {
		panic(err)
	}
	bytes, err := ioutil.ReadAll(conn)
	if err != nil {
		panic(err)
	}
	fmt.Println("Received: ", string(bytes))
}

Run with go run main.go:

127.0.0.1:8080
Waiting for new connections...
Received:  Hello!

Run with GOOS=js GOARCH=wasm go run -exec="$(go env GOROOT)/misc/wasm/go_js_wasm_exec" main.go:

127.0.0.1:1
Waiting for new connections...
panic: dial tcp 127.0.0.1:8080: Connection refused

goroutine 6 [running]:
main.main.func1()
	/Users/alex/programming/go/src/github.com/albrow/wasm-listen-port-bug/main.go:20 +0x25
created by main.main
	/Users/alex/programming/go/src/github.com/albrow/wasm-listen-port-bug/main.go:17 +0x17
exit status 2

Interestingly, it works if you change the code to net.Listen("tcp", "127.0.0.1:1") and net.Dial("tcp", "127.0.0.1:1") since that is the port first returned by nextPort().

See #30324.

The package net on JS is fake and incomplete. I guess http://golang.org/cl/120958 fixes this issue.

Yes, I understand the implementation is fake. Still, it seems that there was some effort to make it sort of work, and correcting the port numbers would make it a lot more useful.

Specifically, I'm writing some tests for Go code and I want to make sure it works when compiled to WebAssembly. There's a lot of code to test, but under the hood I am trying to dial a net.Listener. Since dialing (which is only a small part of the functionality I am trying to test) doesn't work correctly, the whole test fails.

If http://golang.org/cl/120958 fixes this I'm okay with waiting. Any idea when that might land?

Any idea when that might land?

Then, I will try to catch the Go 1.13 release train. Please be informed that it's not rare that CLs from alien contributors like me will take a bit long time for landing, sometimes a year or two, as CL 120958 was written during the last year's football world cup games and still has no review yet.