-
Notifications
You must be signed in to change notification settings - Fork 10k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
@onevent:preventDefault does not trigger when event is not already registered #18449
Comments
@poke thanks for contacting us. @poke what you are mentioning makes sense. @SteveSandersonMS do you have any thoughts here? |
@poke on a second look, I think the current behavior is actually fine. I think that as a rule, for simplicity we want to keep the behavior where The reason is for simplicity and consistency within the language. If we were to do so, every time we introduce a new modifier we will have to think if it makes sense to apply it in isolation or not, and that will make the rule for modifiers very complicated (as it would depend on the modifier being applied). The alternative, even though it requires a bit more code is simpler to understand and explain. If you want to apply some modifier /cc: @SteveSandersonMS in case he has other thoughts. |
But that’s not what is the case here. Please note that in my example, I use Your statement makes it sound as if you would need to put both on the same element like this: <button @onclick="Click"
@onmousedown="() => { }"
@onmousedown:preventDefault>Test</button> If that was the case, I would probably accept this (although I would really dislike it). But the thing is that you do not need The fact that this is so disconnected from the I understand the desire to keep the |
There's been a bit of confusion here. I think there is a bug to be addressed here.
That's not how this was designed - see #14517:
I do agree there are valid use cases for using preventDefault/stopPropagation independently of handlers for the same event on the same element; that's something we always intended to support and in fact do support today. The bug is when you happen not to have any handlers for a given event type anywhere in the document. |
@SteveSandersonMS Thanks a lot for the clarification :) |
any updates? |
@SteveSandersonMS @javiercn Is this something we think we can still address for .NET 7? Or is the risk too high at this point? |
@danroth27 Let's discuss it with the team. I don't think the risk is particularly high though if we implemented a fix we'd have a more precise sense of how disruptive the change is. |
Thanks for contacting us. We're moving this issue to the |
This is still the issue.
In JS, simple |
Thanks for contacting us. We're moving this issue to the |
Thanks for contacting us. We're moving this issue to the |
the new record: +4 years 😲 still no update for this issue? |
There's no need for this. |
Mudblazor has a working solution for that: https://mudblazor.com/components/swipearea#prevent-default-browser-behavior |
It's an ugly workaround. We really hope that this issue will be addressed together with #24932 |
When using the new
@onevent:preventDefault
directive to prevent the default event behavior for events, I noticed that in order for this to work, there needs to be a@onevent
handler registered anywhere on the page.Apparently, server-side Blazor registers every event just once on the document instead of on individual elements. So e.g.
@onclick="…"
causes theclick
event to be subscribed on the document. Just using@onclick:preventDefault
on the page does not appear to register this global event handler on document, so thepreventDefault()
call is also never made in the handler.My use case for this is managing focus with buttons: When you click a button, then the button stays focused after clicking it, causing the focused style to be applied. In order to avoid this, you can subscribe to the
mousedown
event in JavaScript and just prevent the default behavior:Doing the same in Blazor would look like this:
This however does not work if there isn’t also some
mousedown
handler registered somewhere. As soon as you add one literally anywhere, it works:This is using server-side Blazor on ASP.NET Core 3.1.
The text was updated successfully, but these errors were encountered: