Trigger modifier "from" prevents default behaviour of some input fields

[pfiadDi]

Hi,

I came across a bug with versions 1.9.X and 2.X. When I use hx-trigger="click from:body" or more useful ones like hx-trigger="click[event.target.matches('button#btnid')] from:body", any checkboxes can't be selected anymore, and any input field of type date doesn't show a datepicker flyout anymore.

The moment you remove the modifier, the input fields work as expected.

Here is an example code to reproduce: EDIT: link to working JS Fidddle Thank you Br

EDIT: Better description after investigation:

• htmx prevents the default behaviour after a click on a form
• if a form is triggered by a click modified by from:body (e.g. click from:body, click[event.target.matches('button#dynamicallyAddedElement')] from:body) not only the form def. behaviour is prevented, also that of the clicked element.
• That means, datepicker flyouts for input type dates don't work, checkboxes can't be selected etc.

[Telroshan]

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?

[pfiadDi]

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.

[Telroshan]

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: https://github.com/bigskysoftware/htmx/blob/0f70de7c0f8da72b3667fa7aef44636e51caf94e/src/htmx.js#L2307-L2315

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!

[pfiadDi]

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.