Svelte 5: dispatched "native named" events not reaching handler #12147
Comments
|
Looks like they now need "bubbles" set on the custom event: input.dispatchEvent(new CustomEvent('input', { bubbles: true })) |
|
Hmmn, I say it works ... for the example it does, for something in a separate package it doesn't seem to. I'll test it some more. |
|
The problem is that manually created events don't bubble by default and actual dom events without the colon use the global listener (which requires bubbling to work). So when you switch to colonless events the native events gets delegated to the body but your dispatched event never reaches the body. I don't think there's a way to fix this without either removing the delegated events thing (which I don't think is feasible now) or monkey patching dispatch event. I wonder if a decent workaround could be listening to the capture phase and check if the event will bubble and if not dispatch a new event that bubbles. But I fear this could get more convoluted than necessary |
|
Can |
I guess the problem is if libraries are using this, if it's user lang code you can just add bubble: true |
|
Are you missing the bit about behavior changing depending on the event name? Not only is it different to how it used to behave, it's also inconsistent. I need to confirm if bubbles worked from library code, when I tried it last night it didn't appear to, but it was late and I may have been doing something stupid. Update: I was doing something stupid! (set bubbles on event detail instead of the event itself) |
Nope I've actually explained why that happen.
With bubble it should work. |
|
Maybe I'm not explaining it well. I know the trusted events that the browser dispatches work, but all the events dispatched from clicking the button in the example are manually dispatched, and the one with the name "custom" works without Another question: what if you don't want an event to bubble? The listener and dispatch are both on the same DOM element so bubbling shouldn't be needed. |
Because the only events that are delegated are the "non custom" ones |
Why? They are all custom events, and none of the events are set to bubble, but one does? It changes how events worked with the For comparison, without Svelte, it works how I'd expect - the events only reach the <!DOCTYPE html>
<div id="div">
<input id="input" type="text">
<button id="bubbles">bubbles</button>
<button id="regular">regular</button>
</div>
<script>
function handle(name) {
return function(e) {
console.log(name, e.type)
}
}
div.addEventListener('input', handle('div'))
div.addEventListener('custom', handle('div'))
input.addEventListener('input', handle('input'))
input.addEventListener('custom', handle('input'))
bubbles.addEventListener('click', () => {
input.dispatchEvent(new CustomEvent('input', { bubbles: true }))
input.dispatchEvent(new CustomEvent('custom', { bubbles: true }))
})
regular.addEventListener('click', () => {
input.dispatchEvent(new CustomEvent('input'))
input.dispatchEvent(new CustomEvent('custom'))
})
</script> |
What I mean is that click is a known Dom event so it's delegated to the body because they can add a global click listener and run all the events that bubbles. "custom" is not a known Dom event so they can't do that and so they add the listener to the Dom element itself. Since none of your events bubbles the only one logged is "custom" that is attached to the Dom element and not to the body. I'm not saying is desiderabile. I'm just explaining why it's happening. |
|
It seems like a simplistic / fundamentally flawed approach to me from my (possibly limited) understanding. You can't really tell from the event name / type whether the event you're going to get will be a custom event or a native event (as in "dispatched by the browser" vs "dispatched programatically"). AFAIK the only way to check is by looking at the event itself, e.g. for the This seems like a step backwards. It breaks expectations of how HTML + JS work. I'd much rather have correct & consistent than something that may only usually be of benefit to benchmark runs. |
CaptainCodeman
changed the title
|
A different example, where an imported |
Yeah as I've said this either needs to be documented as a breaking change or fixed in some way. |
|
We just need to document what events are delegated. We only delegate a specific amount of events: https://github.com/sveltejs/svelte/blob/main/packages/svelte/src/constants.js#L37-L61 You only need to pass |
|
I'm guessing using capture mode isn't an option for some reason, even if just to detect and "patch" the behavior for consistency? |
Describe the bug
Manually dispatched events with names matching native events don't reach handlers when new
on...syntax is used vs when olderon:...syntax is used.Reproduction
Click button, 3 events are raised (and also raise if the input is typed in + left):
https://svelte-5-preview.vercel.app/#H4sIAAAAAAAAE5WQwWrDMBBEf0XsJTYY525sQyn9iqoHR17HovJKWKuUIvTvRXJo2mNOYuZpZmEiLNqgh-49Ak0bQgcvzkED_O2y8Dc0jNCAt2FX2em92rXjUZJkgyw0ucCSslwCKdaWxDrRbHCvsBYxA8nKkrcGW2OvFba5vM4gFfo3uk_aY_WbK-3trL2bWK1vNySuCL_Ea_Bst0OfyqdTXT8RUetEV3wyU8Q9kyT158cU1JcKcdE0d7xqP8RiJGGpO44N8T5L8Qr9bx39D2-U1F8Cs6VCjVafQyz7pLE8_fnAIzSw2VkvGmfoeA-YPtIPUdMhYtoBAAA=
Press migrate to switch to runes syntax. Now only the
customevent reaches the handler.i.e. switching from
on:inputtooninputstops the event handler firing for manually dispatched events.Logs
No response
System Info
System: OS: macOS 14.5 CPU: (10) arm64 Apple M1 Pro Memory: 197.67 MB / 16.00 GB Shell: 5.9 - /bin/zsh Binaries: Node: 20.7.0 - ~/Library/pnpm/node npm: 10.1.0 - ~/Library/pnpm/npm pnpm: 9.4.0 - ~/Library/pnpm/pnpm Browsers: Chrome: 126.0.6478.63 Edge: 126.0.2592.68 Safari: 17.5 npmPackages: svelte: 5.0.0-next.160 => 5.0.0-next.160Severity
annoyance
The text was updated successfully, but these errors were encountered: