On wasm, the wasm_exec.js helper passes the command line arguments and
environment variables via a reserved space in the wasm linear memory.
Increase this reserved space from 4096 to 8192 bytes so more environment
variables can fit into the limit.
Later, after https://golang.org/cl/350737 landed, we can switch to the
WASI interface for getting the arguments and environment. This would
remove the limit entirely.
Fixes#49011
Change-Id: I48a6e952a97d33404ed692c98e9b49c5cd6b269b
Reviewed-on: https://go-review.googlesource.com/c/go/+/358194
Trust: Richard Musiol <neelance@gmail.com>
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The list of environments to support with wasm_exec.js was becoming too
large to maintain. With this change, wasm_exec.js expects that the
environment provides all necessary polyfills.
The standardized "globalThis" is used for accessing the environment.
wasm_exec.js now only provides stub fallbacks for globalThis.fs and
globalThis.process.
All code specific to Node.js is now in a separate file.
Change-Id: I076febbd94d4d7845260faad972f450f74a7b983
Reviewed-on: https://go-review.googlesource.com/c/go/+/347353
Trust: Richard Musiol <neelance@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
On Wasm, wasm_exec.js puts command line arguments at the beginning
of the linear memory (following the "zero page"). Currently there
is no limit for this, and a very long command line can overwrite
the program's data section. Prevent this by limiting the command
line to 4096 bytes, and in the linker ensuring the data section
starts at a high enough address (8192).
(Arguably our address assignment on Wasm is a bit confusing. This
is the minimum fix I can come up with.)
Thanks to Ben Lubar for reporting this issue.
Fixes#48797
Fixes CVE-2021-38297
Change-Id: I0f50fbb2a5b6d0d047e3c134a88988d9133e4ab3
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1205933
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/354571
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Current wasm_exec.js does not enable ECMAScript strict mode. But it is
recommended to be enabled because it
1. eliminates some ECMAScript silent errors by changing them to throw
errors
2. fixes mistakes that make it difficult for JavaScript engines to
perform optimizations
3. prohibits some syntax likely to be defined in future versions of
ECMAScript
This commit enables ECMAScript strict mode in wasm_exec.js following the
transition guide:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode/Transitioning_to_strict_modeFixes#47116
Change-Id: Ib8ffceee37e9127698fb51304241f1e429efe83e
Reviewed-on: https://go-review.googlesource.com/c/go/+/334269
Reviewed-by: Richard Musiol <neelance@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Richard Musiol <neelance@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The stack pointer may have changed after a call from JavaScript into Go
code because of stack growth. The normal case already updated the
sp variable accordingly, but the catch case did not yet.
Fixes#45433
Change-Id: I3e0a33381929626f6b21902948935eb5ffb26c96
Reviewed-on: https://go-review.googlesource.com/c/go/+/321936
Trust: Richard Musiol <neelance@gmail.com>
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Change-Id: Iec9de5ca56eb68d524bbaa0668515dbd09ad38a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/314770
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This results in a nicer error message if the argument to Go.run is
omitted or of the wrong type.
Fixes#37000
Change-Id: I7f36d007f41a79b2cea1cebf5cce127786341202
Reviewed-on: https://go-review.googlesource.com/c/go/+/266117
Trust: Richard Musiol <neelance@gmail.com>
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
wasm_exec.js expects that either "require" is available or that the
globals "crypto", "TextEncoder" and "TextDecoder" are already defined.
Report a better error message if this is not the case, suggesting the
use of a polyfill.
Updates #41482
Change-Id: I5473cae15c98ae42e39f5928245b7762e7a5a8bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/261357
Trust: Richard Musiol <neelance@gmail.com>
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
An i32 passed from WebAssembly to JavaScript is always read as a signed
integer. Use the bitshift operator to turn it into an unsigned integer.
Fixes#40923
Change-Id: Ia91ed2145dd2fc3071e2fc22b86ebfcb3c1e9f4f
Reviewed-on: https://go-review.googlesource.com/c/go/+/261358
Trust: Richard Musiol <neelance@gmail.com>
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
JavaScript environments are quite unpredictable because bundlers add
mocks for compatibility and libraries can polute the global namespace.
Detect more of such situations:
- Add check that require("fs") returns an object.
- Fix check that require("fs") returns an non-empty object.
- Add check that "module" is defined.
Fixes#40730
Change-Id: I2ce65fc7db64bbbb0b60eec79a4cfe5c3fec99c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/248758
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In Webpack, require("fs") will always be empty. This behavior throws an error: "fs.writeSync is not function". It happens when you did "fmt.Println".
This PR avoids such problem and use polyfill in wasm_exec.js on Webpack.
Change-Id: I55f2c75ce86b7f84d2d92e8e217b5decfbe3c8a1
GitHub-Last-Rev: aecc847e3f
GitHub-Pull-Request: golang/go#35805
Reviewed-on: https://go-review.googlesource.com/c/go/+/208600
Reviewed-by: Richard Musiol <neelance@gmail.com>
The js.Value struct now contains a pointer, so a finalizer can
determine if the value is not referenced by Go any more.
Unfortunately this breaks Go's == operator with js.Value. This change
adds a new Equal method to check for the equality of two Values.
This is a breaking change. The == operator is now disallowed to
not silently break code.
Additionally the helper methods IsUndefined, IsNull and IsNaN got added.
Fixes#35111
Change-Id: I58a50ca18f477bf51a259c668a8ba15bfa76c955
Reviewed-on: https://go-review.googlesource.com/c/go/+/203600
Run-TryBot: Richard Musiol <neelance@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When running wasm in the browser, the "process" global is not defined.
This causes functions like os.Getpid() to panic, which is unusual.
For example on Windows os.Getpid() returns -1 and does not panic.
This change adds a dummy polyfill for "process" which returns -1 or an
error. It also extends the polyfill for "fs".
Fixes#34627
Replaces CL 199357
Change-Id: Ifeb12fe7e152c517848933a9ab5f6f749896dcef
Reviewed-on: https://go-review.googlesource.com/c/go/+/199698
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The wasm_exec.js wrapper tries to set up the argv and envp following
the UNIX conventions, but doesn't get it quite right, which can cause
runtime.goenv to crash if you get unlucky.
The main problem was that the envp array wasn't terminated with a nil
pointer, so the runtime didn't know when to stop reading the array.
This CL adds that nil pointer to the end of the envp array.
The other problem was harmless, but confusing. In the UNIX convention,
the argv array consists of argc pointers followed by a nil pointer,
followed by the envp array. However, wasm_exec.js put the environment
variable count between the two pointer arrays rather than a nil
pointer. The runtime never looks at this slot, so it didn't matter,
but the break from convention left Cherry and I trying to debug why it
*wasn't* losing any environment variables before we realized that that
layouts happened to be close enough to work. This CL switches to the
UNIX convention of simply terminating the argv array with a nil
pointer.
Change-Id: Ic9a4cd9eabb5dfa599a809b960f9e579b9f1f4db
Reviewed-on: https://go-review.googlesource.com/c/go/+/193417
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Richard Musiol <neelance@gmail.com>
In preparation for general faketime support, this renames the existing
nanotime, walltime, and write functions to nanotime1, walltime1, and
write1 and wraps them with trivial Go functions. This will let us
inject different implementations on all platforms when faketime is
enabled.
Updates #30439.
Change-Id: Ice5ccc513a32a6d89ea051638676d3ee05b00418
Reviewed-on: https://go-review.googlesource.com/c/go/+/192738
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The typed arrays returned by TypedArrayOf were backed by WebAssembly
memory. They became invalid each time we grow the WebAssembly memory.
This made them very error prone and hard to use correctly.
This change removes TypedArrayOf completely and instead introduces
CopyBytesToGo and CopyBytesToJS for copying bytes between a byte
slice and an Uint8Array. This breaking change is still allowed for
the syscall/js package.
Fixes#31980.
Fixes#31812.
Change-Id: I14c76fdd60b48dd517c1593972a56d04965cb272
Reviewed-on: https://go-review.googlesource.com/c/go/+/177537
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Command line arguments containing multi-byte characters were causing
go_js_wasm_exec to crash (RangeError: Source is too large), because
their byte length was not handled correctly. This change fixes the bug.
Fixes#31645.
Change-Id: I7860ebf5b12da37d9d0f43d4b6a22d326a90edaf
Reviewed-on: https://go-review.googlesource.com/c/go/+/173877
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
go_js_wasm_exec was returning with code 0 if WebAssembly.instantiate
failed. This made failing tests show as passed.
Change-Id: Icfb2f42e9f1c3c70ca4a130a61a63cb305edff32
Reviewed-on: https://go-review.googlesource.com/c/go/+/168885
Run-TryBot: Richard Musiol <neelance@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
TryBot is sometimes running into deadlocks on js/wasm. We haven't been
able to reproduce them yet. This workaround is an experiment to resolve
these deadlocks by retrying a missed timeout event.
A timeout event is scheduled by Go to be woken by JavaScript after a
certain amount of time. The checkTimeouts function then checks which
notes to wake by comparing their deadline to nanotime. If this
check fails erroneously then the note may stay asleep forever, causing
a deadlock. This may or may not be the reason of the observed
deadlocks.
Updates #28975.
Change-Id: I46b9d4069307142914f0e7b3acd4e65578319f0b
Reviewed-on: https://go-review.googlesource.com/c/go/+/167119
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change adds support for using wasm with Electron. It refactors
environment detection to a more modular approach instead of explicitly
testing for Node.js.
Fixes#29404
Change-Id: I882a9c56523744e7fd7cb2013d158df91cf91d14
Reviewed-on: https://go-review.googlesource.com/c/164665
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The name "Callback" does not fit to all use cases of js.Callback.
This commit changes its name to Func. Accordingly NewCallback
gets renamed to FuncOf, which matches ValueOf and TypedArrayOf.
The package syscall/js is currently exempt from Go's compatibility
promise and js.Callback is already affected by a breaking change in
this release cycle. See #28711 for details.
Fixes#28711
Change-Id: I2c380970c3822bed6a3893909672c15d0cbe9da3
Reviewed-on: https://go-review.googlesource.com/c/153559
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Using fmt.Scanln in a browser environment caused a panic, since there
was no stub for fs.read. This commit adds a stub that returns ENOSYS.
Fixes#27773.
Change-Id: I79b019039e4bc90da51d71a4edddf3bd7809ff45
Reviewed-on: https://go-review.googlesource.com/c/150617
Run-TryBot: Richard Musiol <neelance@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
os.TempDir() did not return a proper directory on Windows with js/wasm,
because js/wasm only uses the Unix variant of TempDir.
This commit passes the temporary directory provided by Node.js to the
Go runtime by adding it as a default value for the TMPDIR environment
variable. It makes TempDir compatible with all platforms.
Fixes#27306.
Change-Id: I8b17e44cfb2ca41939ab2a4f918698fe330cb8bc
Reviewed-on: https://go-review.googlesource.com/c/150437
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
With this change, callbacks returned by syscall/js.NewCallback
get executed synchronously. This is necessary for the APIs of
many JavaScript libraries.
A callback triggered during a call from Go to JavaScript gets executed
on the same goroutine. A callback triggered by JavaScript's event loop
gets executed on an extra goroutine.
Fixes#26045Fixes#27441
Change-Id: I591b9e85ab851cef0c746c18eba95fb02ea9e85b
Reviewed-on: https://go-review.googlesource.com/c/142004
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This commit adds a check of "process.title" to detect Node.js.
The web app bundler Parcel sets "process" to an empty object. This
incorrectly got detected as Node.js, even though the script was
running in a browser.
Fixes#28364.
Change-Id: Iecac7f8fc3cc4ac7ddb42dd43c5385681a3282de
Reviewed-on: https://go-review.googlesource.com/c/144658
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Before this change running os.Stdout.Sync() in the browser would panic
the application with:
panic: syscall/js: Value.Call: property fsync is not a function, got undefined
Afterwards Sync() becomes a noop for compatibility reasons.
Change-Id: I1fcef694beb35fdee3173f87371e1ff233b15d32
Reviewed-on: https://go-review.googlesource.com/c/143138
Reviewed-by: Richard Musiol <neelance@gmail.com>
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This commit changes the encoding of js.Value so that the zero js.Value
represents the JavaScript value "undefined". This is what users
intuitively expect.
Specifically, the encodings of "undefined" and the number zero have
been swapped.
Fixes#27592.
Change-Id: Icfc832c8cdf7a8a78bd69d20e00a04dbed0ccd10
Reviewed-on: https://go-review.googlesource.com/c/143137
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The commit 0e4c013 changed the syscall package so it uses the
asynchronous functions of Node.js's fs module.
This commit adapts the stubs of the fs module which are used when using
a browser instead of Node.js.
Fixes#28068.
Change-Id: Ic3a6a8aebb0db06402383bc2fea7642a4501e02c
Reviewed-on: https://go-review.googlesource.com/c/140537
Reviewed-by: Agniva De Sarker <agniva.quicksilver@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Edge supports WebAssembly but not TextEncoder or TextDecoder.
This change adds a comment pointing to a polyfill that could
be used. The polyfill is not added by default, because we want to
let the user decide if/how to include the polyfill.
Fixes#27295
Change-Id: I375f58f2168665f549997b368428c398dfbbca1c
Reviewed-on: https://go-review.googlesource.com/139037
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This reverts CL 131718, commit a0e7f12771.
Reason for revert: adds request overhead & dependency on third-party service for all users regardless of whether it's necessary.
Updates #27295
Change-Id: I4a8a9b0c8e4a3198c884dfbd90ba36734f70a9a9
Reviewed-on: https://go-review.googlesource.com/138937
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Edge supports WASM but not TextEncoder or TextDecoder.
This PR adds a polyfill to `misc/wasm/wasm_exec.js` to fix this.
Fixes#27295
Change-Id: Ie35ee5604529b170a5dc380eb286f71bdd691d3e
GitHub-Last-Rev: a587edae28
GitHub-Pull-Request: golang/go#27296
Reviewed-on: https://go-review.googlesource.com/131718
Reviewed-by: Agniva De Sarker <agniva.quicksilver@gmail.com>
Reviewed-by: Richard Musiol <neelance@gmail.com>
The same catch block is there in wasm_exec.js for node processes.
Added it in browser invocations too, to prevent uncaught exceptions.
Change-Id: Icab577ec585fa86df3c76db508b49401bcdb52ae
Reviewed-on: https://go-review.googlesource.com/132916
Reviewed-by: Richard Musiol <neelance@gmail.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When using the compiled .wasm with misc/wasm/wasm_exec.js, we get an error message if the site prohibits eval() via the Content-Security-Policy header. This can be resolved by moving the callback helper code from src/syscall/js/callback.go to misc/wasm/wasm_exec.js.
Fixes#26748
Change-Id: I28f271b8a00631f4c66a1ac31305e85f20f9d420
GitHub-Last-Rev: a6a0268f38
GitHub-Pull-Request: golang/go#26750
Reviewed-on: https://go-review.googlesource.com/127296
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This commit removes O_NONBLOCK on js/wasm. O_SYNC can't be
removed, because it is referenced by the os package, so instead
its use returns an error.
On Windows, the options O_NONBLOCK and O_SYNC are not available
when opening a file with Node.js. This caused the initialization
of the syscall package to panic.
The simplest solution is to not support these two options on js/wasm
at all. Code written for js/wasm is supposed to be portable,
so platform-specific options should not be used.
Fixes#26524.
Change-Id: I366aa3cdcfa59dfa9dc513368259f363ca090f00
Reviewed-on: https://go-review.googlesource.com/126600
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When using callbacks, it is not necessarily a deadlock if there is no
runnable goroutine, since a callback might still be pending. If there
is no callback pending, Node.js simply exits with exit code zero,
which is not desired if the Go program is still considered running.
This is why an explicit check on exit is used to trigger the "deadlock"
error. This CL makes it so this is Go's normal "deadlock" error, which
includes the stack traces of all goroutines.
Updates #26382
Change-Id: If88486684d0517a64f570009a5ea0ad082679a54
Reviewed-on: https://go-review.googlesource.com/123936
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Private fields of the Go class are not used any more after the program
has exited. Delete them to allow JavaScript's garbage collection to
clean up the WebAssembly instance.
Updates #26193.
Change-Id: I349784a49eaad0c22ceedd4f859df97132775537
Reviewed-on: https://go-review.googlesource.com/122296
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Paul Jolly <paul@myitcv.org.uk>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This commits adds Value.Type(), which returns the JavaScript type of
a Value.
The implementation uses two previously unused bits of the NaN payload
to encode type information.
Change-Id: I568609569983791d50d35b8d80c44f3472203511
Reviewed-on: https://go-review.googlesource.com/122375
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
There is no "window" global in a web worker context. Use "self" instead.
Fixes#26192
Change-Id: I6c6f3db6c3d3d9ca00a473f8c18b849bc07a0017
Reviewed-on: https://go-review.googlesource.com/122055
Run-TryBot: Richard Musiol <neelance@gmail.com>
Reviewed-by: Richard Musiol <neelance@gmail.com>
Currently we use a globally unique symbol property on objects that get
passed from JavaScript to Go to store a unique ID that Go then uses when
referring back to the JavaScript object (via js.Value.ref). This
approach fails however when a JavaScript object cannot be modified, i.e.
cannot have new properties added or is frozen. The test that is added as
part of this commit currently fails with:
Cannot add property Symbol(), object is not extensible
Instead we consolidate the string, symbol and object unique ID mapping
into a single map. Map key equality is determined via strict equality,
which is the semantic we want in this situation.
Change-Id: Ieb2b50fc36d3c30e148aa7a41557f3c59cd33766
Reviewed-on: https://go-review.googlesource.com/121799
Run-TryBot: Paul Jolly <paul@myitcv.org.uk>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Richard Musiol <neelance@gmail.com>
For each Javascript object that returns to Go as a js.Value, we
associate the ref id to it. But if this ref id is copied or
inherited to other object, it would mess up the ref-object
mapping.
In storeValue, make sure the object is indeed the one we are
storing. Otherwise allocate a new ref id.
Fixes#26143.
Change-Id: Ie60bb2f8d1533da1bbe6f46045866515ec2af5a9
Reviewed-on: https://go-review.googlesource.com/121835
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Richard Musiol <neelance@gmail.com>
This commit changes how JavaScript values are referenced by Go code.
After this change, a JavaScript value is always represented by the same
ref, even if passed multiple times from JavaScript to Go. This allows
Go's == operator to work as expected on js.Value (strict equality).
Additionally, the performance of some operations of the syscall/js
package got improved by saving additional roundtrips to JavaScript code.
Fixes#25802.
Change-Id: Ide6ffe66c6aa1caf5327a2d3ddbe48fe7c180461
Reviewed-on: https://go-review.googlesource.com/120561
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently wasm_exec.js is executable (0755) yet has no interpreter.
Indeed wasm_exec.js is only ever used as an argument to Node or loaded
via a <script> tag in a browser-loaded HTML file. Hence the execute
mode bits are superfluous and simply serve to clutter your PATH if
$GOROOT/misc/wasm is on your PATH (as is required if you want to run go
test syscall/js).
Change-Id: I279e2457094f8a12b9bf380ad7f1a9f47b22fc96
Reviewed-on: https://go-review.googlesource.com/120435
Run-TryBot: Paul Jolly <paul@myitcv.org.uk>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
1. Make import functions not use the js.Value type directly,
but only the ref field. This gives more flexibility on the Go side
for the js.Value type, which is a preparation for adding
garbage collection of js.Value.
2. Turn import functions which are methods of js.Value into
package-level functions. This is necessary to make vet happy.
Change-Id: I69959bf1fbea0a0b99a552a1112ffcd0c024e9b8
Reviewed-on: https://go-review.googlesource.com/118656
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This stub is necessary so the time package can fail to load
the timezone files in a nice way. It transitively makes the
log package work in browsers.
Change-Id: I4d360df82989d9b40cd31bb4508a6d057534443e
Reviewed-on: https://go-review.googlesource.com/118977
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
