When the response contains "HX-Redirect" the hx-indicator element is not deactivated. (htmx-v2)

[VisionovaDev]

When the response contains "HX-Redirect" the hx-indicator element is not deactivated. The HX-Redirect header is set to redirect the browser to another page so someone could be think that hx-indicator element deactivation is not needed, but if the redirect is toward a file download link the browser page is not reloaded so the hx-indicator element should be deactivated.

[zyriab]

Are you using hx-disabled-elt?

Or maybe I'm not understanding something... You can deactivate the element manually with some JS or by returning a deactivated element. The hx-indicator class is only added to the element during the request, afaik.

[VisionovaDev]

I am sorry I have not explained the problem in the right manner. Usually when I set the attribute hx-indicator="#spinner" the element with id="spinner" is shown (because htmx library add some classes) when the htmx ajax call begin. Eventually it is hidden (again by htmx library) when the ajax call is finished. The problem is that when the backend returns an hx-redirect in the header the second part doesn't happen and the spinner element remain visibile.

[zyriab]

Oh I see! (Sorry for the delay btw) Have you checked with htmx.logAll() if the after-request event was fired? Without knowing more (and also being an htmx noob), it seems you found a bug.

[VisionovaDev]

I checked and found that after-request event is fired.

[Telroshan]

Hey, the fact that spinners are not removed upon HX-Redirect is actually on purpose, see 116c8619d5e6301e8df71f0d3caf32e8660b9096, where it would otherwise look weird to have the spinner be gone for a few frames before the actual page change

If I understand correctly here, you redirect to a page that triggers a download, thus doesn't actually change the active page?

I wonder if that's a situation possible to identify at the htmx level... I'm really not sure of that as we simply set location.href = in this case.

Btw, if I understand correctly, this means that every subsequent page refresh would trigger the download again as the page URL changed ; is that what you want here? Because if not, I'm thinking you might want to use another mechanism than HX-Redirect in this case (such as responding with a hidden link, that points to the downloadable URL with the download attribute set, and trigger a click on it, instead of directly redirecting to the downloadable URL)

[VisionovaDev]

The page doesn't change because the redirect is toward a "file download" link. On page refresh the download is not triggered again. I recap the case: I have a button that onclick trigger execute a hx-post call to the backend. The backend create a pdf file and generates an unique temporary url to download the pdf file created. The backend return to the htmx call an header with HX-Reditect to redirect the browser to the file download link. The browser executes the download All works as expected but the hx-inidcator remain in the state of "waiting htmx response" as if the backend never answers.

[Telroshan]

Thanks for the details From the top of my head I really don't know whether we can identify such a case from htmx itself. We'd need a way to hook somehow to the browser applying the location.href value change, which results in a HTTP request, where the browser likely eventually doesn't change the page URL because of that request's headers that trigger a download. We'd need to hook to that specific moment and remove indicators if this didn't result in an actual page change. I have no idea atm whether we can do such a thing or not. If that is not possible at all, maybe we should consider adding a header option to keep or dismiss indicators? Thinking out loud though

If you are interested to look into it, please feel free to work on a PR that would resolve this situation. Other than that, I would encourage you to use a workaround/fallback method in the meantime, such as a download link hidden in the server response that you trigger a click onto

[MoritzR]

I have the same issue and use case and am currently fixing it by sending a HX-Trigger header and then listening to that:

<button id="download-button" hx-get="/download">Download</button>
<script>
    document.getElementById("download-button").addEventListener("downloadReady", function () {
        // workaround for htmx not automatically doing this when redirecting
        this.classList.remove("htmx-request");
    });
</script>

This is a somewhat easy fix. Still, this was my very first time using HTMX and this will stick with me as HTMX being buggy, which is unfortunate as I really enjoyed it otherwise.