Trigger modifier "from" prevents default behaviour of some input fields about htmx HOT 4 OPEN

Thank you - maybe I'll give it a try. Would be interesting to learn more about htmx by trying ...
Edit:
The bug prevails also when the elements are inside the form and there is a normal click trigger (without modifier) on the form element.

Edit 2: @Telroshan you are right. When I change this function to return false the elements work as expected.

from htmx.

Hey, I'm not sure I understand the issue here.

See this JSFiddle, I copied your example above and added for ex a <div hx-get="/test" hx-trigger="click[event.target.matches('button#btnid')] from:body">

When I click the button, a request is correctly fired, and the date input + checkbox correctly work for me, did I miss something?

from htmx.

Hey @Telroshan , I am sorry I haven't seen your reply earlier. And my example code was trashed by github.
This was my original example:
https://jsfiddle.net/et4j60bp/

I can confirm, when a div is triggered it works but in my example I tried to trigger a form - in this case it doesn't work.

(in my app I have fields outside of a form and store selected values in a form with hidden inputs - after click on some elements I want to trigger the form) in this case the bug arises.

For now I was able to avoid it by triggering my form via JS and removing the hx-trigger element from the form.

from htmx.

Ooooh ok I understand now, thanks for the JSFiddle @pfiadDi.

Seems to be an unhandled specifity of the from modifier indeed ; I can see in htmx's code that the function determining whether an event should be default prevented checks this:

The issue here being that the we indeed have a click event, and the element against which the tag name is checked, is the form itself and not the element that triggered the event (which would here be the date or checkbox input).
So, in this case, event.preventDefault is called, which explains why the inputs don't work anymore ; their native behavior has been canceled by htmx.

In the JSFiddle that you sent, we can confirm this by changing the form tag to a div and suddenly the inputs work again 😅
So, it definitely looks like a bug to me; feel free to open a bugfix PR if you feel like it!

My gut guess would be that we could simply need to check the tag name of the event's target instead of the listening element itself. Though, will it be enough, and won't it break any other behavior ? The test suite will tell us!

from htmx.