Don't preventDefault on events that are filtered

[HeyHugo]

Run the maybeFilterEvent() check before evt.preventDefault() so that events excluded via hx-trigger filters are ignored and not prevented.

Prior to this change <a href="/some/url" hx-get="/some/url" hx-trigger="click[!ctrlKey && !metaKey]"> would not let the browser use default ctrl + click behaviour due to the event being prevented.

This PR makes the suggestion here viable without adding another event listener on your own.

For a bit of context I have a use case where it makes sense to use hx-get on a <a> tag. It's a modal/overlay thing using hx-push-url and hx-history-elt. Direct browsing to the url makes sense and I'd really like to keep <a> ctrl/meta + click behaviour for the specific link. My current solution is to add another event listener specifically for click + modifier and then do window.open("/some/url", "_blank").

My workaround is to add something like this:

  const link = document.querySelector("#some-container a");
  const url = link.getAttribute('href');
  link.addEventListener("click", function (e) {
    if (e.metaKey || e.ctrlKey) {
      e.preventDefault();
      window.open(url, "_blank");
    }
  });

It works but requires me to reimplement the default browser behaviour with another event listener. I think it'd make sense in the general case that if you filter an event out explicitly it keeps whatever default there is.

[HeyHugo]

@alexpetros Aha a test had to be updated. Did so now, can you trigger workflow again 🙏

[alexpetros]

Labeling this a bug because I think this is how it should work anyway. Want to be careful there's no unintended regression but I personally am pro this change.

[judyburgett3]

thank you

[HeyHugo]

@judyburgett3 Spamming won't help.

Meanwhile you can use the workaround I posted above.

[alexpetros]

Thanks Hugo. This is going to be looked at for 1.9.6 btw

[judyburgett3]

please make the changes. thank you.

[judyburgett3]

make the changes

[judyburgett3]

thank you

[alexpetros]

Is this a chance in behavior that could cause possible regressions?

[HeyHugo]

I would say no. If by any chance you rely on the event excluded by the filter preventing the default of that event you rely on a "bug" behavior.

There could be a case where someone is using a filter on a <a> element and relying on the behavior that any clicks even those excluded by filter does not navigate the user away. In this case one could say it's a regression, but I'd argue:

Why are you using an <a> element with href attribute if you don't intend to navigate the user? Perhaps replace it with a button.

It'd be an extremely rare regression worth the change to allow ctrl/meta + click links by only adding a filter.

[1cg]

what about someone who has an event filter on a form that has an hx-post on it?

if this change is accepted, the form would submit if the filter was false, no?

i see what you are saying here, but I think that this change might be a little too aggressive.

[HeyHugo]

Hmm yes the filter on form / submit button case would have changed behaviour 🤔
I see this might be too breaking then.

There's probably no smoother way to support ctrl/meta-click default other than doing what I already did with a custom event-listener reimplement target="_blank"

[alexpetros]

Related: #1456

[1cg]

OK, closing this out for now although we should probably make this use case addressable some way, either via additional syntax in the trigger, events, etc. Thank you for your efforts here!