That looks like a bug in pointer internalization. Here it seems to only handle pointers to structs: https://github.com/gopherjs/gopherjs/blob/fbc70fee0b646e68ae0ecfe4bfef7ddf359cbf45/compiler/prelude/jsmapping.js#L330-L332C14

Moreover, there is no break, so it probably falls through to the next case and does something entirely incorrect.

@nevkontakte
is it just me, or is the fix as straightforward as they come?
we just need to remove the if statement, and let it internalize the actual type(regardless of the kind)

Unfortunately, no. Pointers in GopherJS are kind of weird and have a lot of special cases (which is probably why they aren't handled properly here). For example, structs and pointers to structs are represented by the same underlying JS object, but pointer to a number is a special kind of object. Depending in which context a pointer is create it may also be a slightly different kind of object. Off the top of my head I won't be able to remember all the rules that apply here. And I'm not even going to touch unsafe.Pointer, which is a whole separate can of worms :)

One of those days I want to sit down, reverse-engineer and document properly how pointers work, but that day hasn't come yet.

how can I help to promote this?
I can help with the research and later write the code if needed

for my use case, this issue is pretty critical to solve, so I do like to push it forward

As always, your contribution will be very welcome. If I were to do this, my goal would be to understand how pointers to different types are working (e.g. ints, strings, slices, slice elements, structs, struct fields, etc.). I would probably start with looking at implementation of the address-taking operator (&). I would also take a look how externalization of pointers works, and see if I can come up with the inverse of it.

Let me know if you have more questions :)