The existing `mem.make_map` passes a capacity, but the builtin
`make_map` no longer takes a capacity--it was separated to
`make_map_cap` to allow for making a map without an allocation (#4340).
`core:mem` was not updated to reflect this, so any usage of `mem.make`
to make a map will currently result in a compile error.
There are several places where this is assumed to be true, most visibly
in `is_path_separator`, as it takes a `byte` argument.
Note that the data type of `_Path_Separator` is a rune, which allows any
Unicode value.
There were multiple issues here:
1. listeners stored in the same key overwriting the previous one
2. missing `use_capture` parameter in `remove_event_listener`/`remove_window_event_listener`
The key used to store the listener function in `listenerMap` was a
javascript `Object`, when used as a key it was thus serialized to
the string `"[object Object]"`, meaning all listeners where effectively
set to the same key when calling `add_event_listener`/`add_window_event_listener`.
Later on when calling `remove_event_listener`/`remove_window_event_listener`,
it then tried to remove the incorrect one or none at all if there was a
mix of the same event name registered on an element or the window.
To fix I implemented a function `listener_key` in the javascript code
which will generate a different key based on the event's:
- `id`: dom element's id or 'window' (when event listener added to the
window)
- `name`: the event name (eg: `click`), each event handler should be
removed for the event name it was register on.
- `data`: we can register events with different data, each one generate
a new listener which has to be removed.
- `callback`: same as `data`, if you register two similar handler but
with two different callback, each one should be removed.
- `useCapture`: this one is a bit tricky, but when you register an event
handler in javascript, if you don't pass `useCapture`, it defaults to `false`.
When you remove an handler, you have to pass the exact same
`useCapture` option you registered it with. In this case, we allowed
to register an event with different `useCapture`, but didn't allow to
pass the `useCapture` when removing it. We always called `removeEventListener`
without the `useCapture` parameter which removed the handler properly
only when it was registered with `useCapture=false`.
I also switched the `WasmMemoryInterface.listenerMap` from `{}`
(javascript object) to a `new Map()`, which is available everywhere
nowadays.
`GetParameter4i` can be used to retrieve the current scissor rect, or
the curent viewport, which was previously impossible.
Also adds `BlendEquationSeparate` which seemed to be missing.
Also removes an instance of `do`.
1. Properly set `id` and `mapping` on the `get_gamepad_state` result
2. Increase `id` limit to 96 bytes, connecting my DualShock 4 made it crash
3. If an `id` or `mapping` is longer than the limits, slice it and add `...`
Switched to a recursive mutex so that procedures which need to perform
lookups can do so while also maintaining the lock across their entire
body in order to guarantee atomicity for each environment operation.
