addEventListener('message') conflicts with wasm-bindgen's internal handler

[jiangheng90]

Steps to reproduce

1. Use #[webworker_fn] or #[webworker_channel_fn] with a worker pool
2. The worker has addEventListener('message', handler) for task dispatch
3. Send several tasks to the pool

Expected

Only the addEventListener handler processes messages.

Actual

Both addEventListener and wasm-bindgen's internally registered handler fire.
The wasm-bindgen handler receives wasmworker's {id, func_name, is_channel, arg}
format and fails:

TypeError: Cannot read properties of undefined (reading 'length')
Could not deserialize response

Root cause

mod.default() during init registers a message handler (via self.onmessage
setter). Subsequent addEventListener('message', ...) adds a second handler,
and both fire for every postMessage.

Proposed fix

Lock onmessage via Object.defineProperty with a no-op setter after
mod.default(), so addEventListener remains the sole dispatch path.

See commit: 200ec0e
PR: #25

[paberr]

True, any message handler registered inside the worker during module init will also receive wasmworker's task messages, since dispatch currently uses the worker's default channel.

One question on the root cause: normally wasm-bindgen --target web doesn't set self.onmessage in default().
Does your module have a #[wasm_bindgen(start)] entry point or use a threading helper (wasm-bindgen-rayon / wasm_thread)?

[jiangheng90]

@paberr no I do not use #[wasm_bindgen(start)]. My design purpose is a bit complex. I am using your crate in my Bevy project. Since Bevy's WASM target degrades the code originally running on compute threads to synchronous execution on the main thread, I designed a module that packages all hot-path functions into multi-threaded WASM worker code via your #[webworker_fn] macro. I then manually load the WebAssembly JavaScript and initialize the Web Workers.

[paberr]

Should have been fixed by #25