net/http: Fetch API-based Transport is accidentally disabled too widely

[dmitshur]

During the Go 1.21 dev cycle, we updated from Node 14 to 18, which seems to provide the Fetch API, at least enough to cause it to be turned on during tests and not use the fake network. Since the HTTP server part is still implemented only as a fake network, that caused all tests/examples that start an HTTP server and send requests to it to fail. See #57613 for details.

Unfortunately the current implementation of jsFetchDisabled:

go/src/net/http/roundtrip_js.go

Lines 47 to 51 in 9fc8436

	// jsFetchDisabled will be true if the "process" global is present.
	// We use this as an indicator that we're running in Node.js. We
	// want to disable the Fetch API in Node.js because it breaks
	// our wasm tests. See https://go.dev/issue/57613 for more information.
	var jsFetchDisabled = !js.Global().Get("process").IsUndefined()

Intersects poorly with wasm_exec.js that sets a "process" global whenever it's not already there:

go/misc/wasm/wasm_exec.js

Lines 62 to 73 in 9fc8436

	globalThis.process = {
	getuid() { return -1; },
	getgid() { return -1; },
	geteuid() { return -1; },
	getegid() { return -1; },
	getgroups() { throw enosys(); },
	pid: -1,
	ppid: -1,
	umask() { throw enosys(); },
	cwd() { throw enosys(); },
	chdir() { throw enosys(); },
	}

So it ends up inadvertently disabling Fetch API not only during testing as intended, but also in browsers that use an unmodified copy of wasm_exec.js.

CC @golang/js, @golang/wasm.

[gopherbot]

Change https://go.dev/cl/503675 mentions this issue: net/http: only disable Fetch API in tests