Awesome, thanks @flimzy! This is really helpful.

A test would be quite nice, so this doesn't regress, and so that it's easier to fix this again if it doesn't work on some inputs. Would it be easy for you to add one?

As far as the implementation goes, LGTM if it works (which I understand it does). But it's not easy to debug without seeing sample input that it runs on.

Also, will it work if the URL has a colon like http://localhost:8080?

Would it be easy for you to add one?

Sure, I'll try to add that (it may be the weekend before I have the time).

Also, will it work if the URL has a colon like http://localhost:8080?

Yes.

What's the best way to test this functionality? I started by adding a test in the runtime package, but discovered we aren't running tests against that, presumably because the runtime package has a very bare implementation, and most tests fail.

Should I overwrite those failing tests with no-op tests, so that other package tests will run? Or is there some other mechanism I can utilize for this?

What's the best way to test this functionality?

Whatever is easiest. You don't need to place the test in runtime, especially if getting other runtime tests to skip/pass is a lot of overhead.

You can place a small test in github.com/gopherjs/gopherjs/tests package. Just, something that fails because this fix, and succeeds after.

If it's too hard to add a test, then it's likely easier to skip adding one and fix this if it regresses. I don't want to make you go out of the way and spend a disproportionately large amount of time figuring out how this can be tested.

I'm finally looking at this again.

I would love to be able to create a simple stack-parsing method, which could be tested by passing in a string, the result of js.Global.Get("Error").New().Get("stack"). This would make it quite easy to test the stack traces from arbitrary runtime engines (V8, Firefox, IE, etc) regardless of the runtime actually executing the tests.

The trouble is: Where to put this function and its associated tests?

I tried putting them in compiler/natives/src/runtime, but running tests there is nearly, if not outright, impossible, in GopherJS.

My next try was to put them in compiler/natives/src/runtime/internal/sys/arch_js.go, but the compiler explicitly ignores runtime/internal, and changing that is probably even more difficult than running tests in runtime.

My next attempt was to create compiler/natives/src/runtime/jsinternal, which would house a ParseStack function, to be called by the runtime package. I expect I'd have to override that the runtime package is allowed to import this additional package, but that seems minor. However with this go test -v -race ./... has countless failures:

# go run run.go -- fixedbugs/issue9604.go
exit status 1
cannot find package "runtime/jsinternal" in any of:
        /usr/local/go/src/vendor/runtime/jsinternal (vendor tree)
        /usr/local/go/src/runtime/jsinternal (from $GOROOT)
        /home/jonhall/go/src/runtime/jsinternal (from $GOPATH)

FAIL    fixedbugs/issue9604.go  0.019s

I'm not sure where this leaves me.

One option would be to not write this function, or the tests, in Go at all. I could write it all in pure JS. But that doesn't seem like a very Go-friendly solution, either.

Any other suggestions? Or should we forgo tests on this change?

I would love to be able to create a simple stack-parsing method, which could be tested by passing in a string, the result of js.Global.Get("Error").New().Get("stack"). This would make it quite easy to test the stack traces from arbitrary runtime engines (V8, Firefox, IE, etc) regardless of the runtime actually executing the tests.

Indeed, that's what I was hoping for.

I tried putting them in compiler/natives/src/runtime, but running tests there is nearly, if not outright, impossible, in GopherJS.

Can you elaborate on this? This sounds like the best solution, so what's stopping it from working?