"htmx:abort" not cancelling the pending AJAX request. #3269

bennadel · 2025-04-07T11:22:53Z

bennadel
Apr 7, 2025

I am working on an "active search" demo with a loading indicator. And, to make sure the loading indicator works, I've added a 2-second delay to my search results. However, I'm seeing a strange issue in which:

The user types into the input which triggers a search (takes at least 2-seconds to run).
The user clicks on one of the existing search results, taking them away from the current view while the above request is still running.
A new UI (contact detail) renders.
The earlier active search AJAX completes.
The hx-push-url from the search page updates the browser location even though that UI is no longer rendered.

To get around this, I've tried to trigger an htmx:abort event on the active search input when the element unloads; but, it doesn't seem to actually do anything. Here's my input code. Three things to note:

I have an hx-sync on the form (to synchronize the active search and the form submission).
I have hx-push-url="true" on the active search input.
I have an hx-on:htmx:before-cleanup-element on the input.

<form method="get" hx-sync="this:replace">
	<label for="search">
		Search contacts:
	</label>
	<input
		id="search"
		type="text"
		name="q"
		value=""

		hx-get="index.cfm"
		hx-push-url="true"

		hx-trigger="input delay:200ms"
		hx-target=".search-results"
		hx-select=".search-results"
		hx-select-oob="pagination"

		hx-on:htmx:before-cleanup-element="
			console.log('here', this);
			htmx.trigger(this, 'htmx:abort');
			htmx.trigger('form', 'htmx:abort');
		"

		hx-indicator="#search-busy"
	/>
	<button type="submit">
		Search
	</button>

I can see from the console.log("here") that the before-cleanup-element event is being fired. However, I can see from the browser network activity that the pending request isn't being aborted; which is why, I presume, I'm seeing the active search URL get pushed onto the history even after I've navigated away.

I feel like I must be missing something very subtle. Not sure if the hx-sync is messing things up. Or, if maybe the AJAX queue is no longer bound to the element at the time the before-cleanup-element event is fired. Thanks for any advice!

Telroshan · 2025-04-08T07:31:21Z

Telroshan
Apr 8, 2025
Maintainer

Hey, it's weird that the htmx:abort is not working 🤔

Could you show your HTML code for search-results?
I would expect you could use hx-sync on those as well so that clicking on a search result automatically cancels any in-flight search input request (which would remove the need for the inline beforeCleanup event handler).

Other than that, could you try adding a log of this['htmx-internal-data'].xhr? Htmx stores the element's request in this internal property, just to see whether you see the XHR from the event or not.
If you see it, could you try calling its abort() method from that inline event handler as well?
If this abortion works, this would indicate that something is wrong with htmx's htmx:abort event. If it doesn't work either, it likely means that the XHR is not abortable anymore, in which case htmx couldn't do much about it.

Hope this helps!

6 replies

bennadel Apr 8, 2025
Author

Ok, I think I'm just gonna side-step the problem by changing the root sync strategy to replace. If I remove all the hx-sync stuff from the form and the active search, and then update the body to be:

<body hx-boost="true" hx-sync="this:replace">

... then it all sort of "just works." I wish I had a better understanding about why the default strategy isn't replace. Because I'm sure it's a set of trade-offs and I don't understand the reasoning so I don't understand what I'm losing out on by changing it. I would presume that this is the behavior (replace) that browser is doing natively (ie, when you're not boosting the experience).

Anyway, I still don't understand why my original approach wasn't working; but, this gets me close enough for now.

bennadel Apr 8, 2025
Author

One more quick follow-up. If I remove the hx-sync from the body (my earlier work-around), and only have the hx-sync on the form, and move the hx-on binding to the form, everything seems to work:

<form
	method="get"

	hx-sync="this:replace"
	hx-on:htmx:before-cleanup-element="htmx.trigger( this, 'htmx:abort' );"

	class="linear-form">

This seems to:

Use the hx-sync for both the form and the nested input with active search.
Cancel any in-flight requests for the active search.
The hx-on:htmx:before-cleanup-element event is showing a valid .xhr property, and will cancel any in-flight active search requests if / when the user navigates away from the current boosted view.

Looking at the source code for HTMX, the "clean up" workflow seems to walk down the DOM tree. So, my best guess here is that by the time the hx-on got to the input, where my original event binding was, the parent form tag has already been cleaned-up and the xhr was no longer available. Just a guess though. And, by moving the hx-on to the form tag, the node hasn't quite been clean-up yet, so the xhr is still available.

That said, I think I still want to just move hx-sync="this:replace" to the body tag, since that feels like a more expected behavior for the browser.

Telroshan Apr 9, 2025
Maintainer

Your guess is totally correct; the xhr is attached to hx-sync element instead of the triggering element
https://github.com/bigskysoftware/htmx/blob/6836e87a6cc3919b7f4679aec6712ee4bc340196/src/htmx.js#L4238C7-L4238C41

And as you noticed, cleanup walks down the DOM. "hasn't quite been clean-up yet" is totally correct, and is the purpose of the beforeCleanup event:

https://github.com/bigskysoftware/htmx/blob/6836e87a6cc3919b7f4679aec6712ee4bc340196/src/htmx.js#L1678C12-L1687

The node itself is cleaned up before its children are, and as it's the synchronized element, its xhr reference is deleted before its children are cleaned up indeed.

By default, each element has an implicit hx-sync of itself + drop strategy. Imagine clicking twice very fast on the same hx-post button, in most cases you won't want that 2nd request from being fired while the first one is still inflight, hence this default behavior that's just here to prevent "double requests".
As soon as you specify hx-sync yourself to implement a more specific behavior, then you may not want the default drop strategy indeed, which is why the attribute lets you customize that.

When you put hx-sync on the body itself, you'd have to be careful, as with default inheritance, it means that ALL elements in the DOM will synchronize over the body ; unless you specifically override/disinherit hx-sync for them, no element could ever have a request in flight while another is, even if that request is unrelated in terms of business logic.
I'm not sure you would want that tbh as it could be the source of many issues as you app grows. But I don't know your app nor your needs, so ofc you be the judge!

Note that in your case, I don't know if you gave a shot to my former suggestion but I still think you could specify hx-sync on your boosted links to target the form with a replace strategy, which should remove the need from calling abort manually from the hx-on handler.
i.e. keep your hx-sync="this:replace" on your form, add an ID to it, let's say id="activeSearchForm", then define hx-sync="#activeSearchForm:replace" on your .search-results div. Didn't test this at all but I'd expect it to work

bennadel Apr 9, 2025
Author

Warning: the following is me basically thinking out loud.

@Telroshan thank you again for the very insightful response. Your constructive criticism vis-a-vis hx-sync on the body has given me pause. In my mind, I was trying to (or at least satisfied with) mimicking what the browser would do naturally without HTMX. That is, if you were to click a long-running link, then navigate to another page, the browser would unload the current page and abort any in-flight requests.

But, I tend to agree with you that this might create subtle bugs in the future if a developer needed to spawn a request and didn't really care if it completed or not - they might not realize that it was being synchronized at the root; and might not realize why the request was being cancelled later on.

Though, I suppose I could also see that as a feature not a bug. Meaning, there might be value to having a developer explicitly identify tasks that can run in parallel and being forced to mark them as such.

But, your point about debouncing accidental double-submissions is also well taken (and allows me to better understand the default behavior, thank you!). Though, at least with forms, I think I can take care of that with the disabled-elt feature (I haven't tried using that one yet).

Oh man, so much to think about. The biggest issue that I can see as I'm playing around with my little app is that if I don't synchronize on the root, the url can randomly change due to a longer-running request. This to me is the most dangerous part about not canceling in flight requests. I actually had a moment where I was on a page with a form that didn't have an action attribute (so the browser will use the current URL). But, just as I was about to submit the form, the URL changed do a background request that was hanging. Then, when I submitted the form, it actually submitted to the wrong URL :D

I think for the time-being, I'm going to leave the hx-sync="this:replace" on the body. Obviously, there are trade-offs all the way down. But, this feels like it will be the most predictable for the moment.

Thank you for letting me just go stream-of-consciousness!

bennadel Apr 10, 2025
Author

Just more of me thinking out loud in case this ever helps anyone else.

I'm realizing now that putting hx-sync on the body will also impact lazy-loaded content. Imagine that I have several elements lower down on the page with hx-trigger="revealed" or even with hx-trigger="load", those will also be impacted. And, with a replace strategy, one lazy-loading request would easily cancel any other lazy-loading request that was already in-flight.

I could always resolve that by putting hx-sync around the things that are lazy-loading; or even, put them on transient elements that do nothing but the lazy loading; so, there is a solution. But, as we discussed above, each developer will have to know that this is necessary and may be a strange thing to debug. That said, it seems like a lesson you would have to learn only once.

Still, this isn't obviously good or bad in my mind. More like I'm just better understanding all of the trade-offs of the various approaches. Even now, I still want to keep the sync on the body since I still think that more closely mirrors the expected browser behavior. I'm just building up a better mental model of all that this implies.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

"htmx:abort" not cancelling the pending AJAX request. #3269

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment 6 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Uh oh!

"htmx:abort" not cancelling the pending AJAX request. #3269

Uh oh!

bennadel Apr 7, 2025

Replies: 1 comment · 6 replies

Uh oh!

Telroshan Apr 8, 2025 Maintainer

Uh oh!

bennadel Apr 8, 2025 Author

Uh oh!

bennadel Apr 8, 2025 Author

Uh oh!

Telroshan Apr 9, 2025 Maintainer

Uh oh!

bennadel Apr 9, 2025 Author

Uh oh!

bennadel Apr 10, 2025 Author

bennadel
Apr 7, 2025

Replies: 1 comment 6 replies

Telroshan
Apr 8, 2025
Maintainer

bennadel Apr 8, 2025
Author

bennadel Apr 8, 2025
Author

Telroshan Apr 9, 2025
Maintainer

bennadel Apr 9, 2025
Author

bennadel Apr 10, 2025
Author