[4.0.0-beta6] No event after hx-disable re-enables element; simple focus() after request is no longer possible

[infogulch]

In Four, hx-disable controls remain disabled throughout __issueRequest with no event fired after they are re-enabled. The issue-request sequence is roughly:

• disable elements
• htmx:before:request
• await fetch
• htmx:before:response
• await response.text()
• htmx:after:request
• htmx:finally:request
• re-enable disabled elements

htmx/src/htmx.js

Lines 579 to 662 in 85b8378

	async __issueRequest(ctx) {
	let elt = ctx.sourceElement
	let syncStrategy = this.__determineSyncStrategy(elt);
	let requestQueue = this.__getRequestQueue(elt);
	if (!requestQueue.issue(ctx, syncStrategy)) return
	ctx.status = "issuing"
	let indicators = [];
	let disableElements = [];
	try {
	// Handle confirmation
	if (ctx.confirm) {
	let confirmed = await new Promise(resolve => {
	let detail = {ctx, issueRequest: () => resolve(true), dropRequest: () => resolve(false)};
	if (this.__trigger(elt, "htmx:confirm", detail)) {
	let js = this.__extractJavascriptContent(ctx.confirm);
	resolve(js ? this.__executeJavaScript(elt, {ctx}, js, true) : window.confirm(ctx.confirm));
	}
	});
	if (!confirmed) return;
	}
	// initialize timeout & indicators after confirmation
	this.__initTimeout(ctx);
	indicators = this.__showIndicators(elt);
	disableElements = this.__disableElements(elt);
	ctx.fetch ||= window.fetch.bind(window)
	if (!this.__trigger(elt, "htmx:before:request", {ctx})) return;
	let response = await ctx.fetch(ctx.request.action, ctx.request);
	ctx.response = {
	raw: response,
	status: response.status,
	headers: response.headers,
	}
	this.__extractHxHeaders(ctx);
	if (!this.__trigger(elt, "htmx:before:response", {ctx})) return;
	ctx.text = await response.text();
	if (!this.__trigger(elt, "htmx:after:request", {ctx})) return;
	if (ctx.response.status >= 400) {
	this.__trigger(elt, "htmx:response:error", {ctx})
	}
	if(this.__handleHeadersAndMaybeReturnEarly(ctx)){
	ctx.keepIndicators = true;
	return
	}
	if (ctx.status === "issuing") {
	if (ctx.hx.retarget) ctx.target = ctx.hx.retarget; // HX-Retarget
	if (ctx.hx.reswap) ctx.swap = ctx.hx.reswap; // HX-Reswap
	if (ctx.hx.reselect) ctx.select = ctx.hx.reselect; // HX-Reselect
	ctx.status = "response received";
	this.__handleStatusCodes(ctx);
	await this.swap(ctx);
	ctx.status = "swapped";
	}
	} catch (error) {
	ctx.status = "error: " + error;
	this.__trigger(elt, "htmx:error", {ctx, error})
	} finally {
	clearTimeout(ctx.requestTimeout);
	if (ctx.hx?.trigger) { // HX-Trigger
	this.__handleTriggerHeader(ctx.hx.trigger, ctx.sourceElement);
	}
	this.__trigger(elt, "htmx:finally:request", {ctx})
	if (!ctx.keepIndicators) {
	this.__hideIndicators(indicators);
	this.__enableElements(disableElements);
	}
	requestQueue.finish()
	if (requestQueue.more()) {
	// intentionally not awaited — __issueRequest has its own try/catch
	this.__issueRequest(requestQueue.next())
	}
	}
	}

---

hx-disable exists to prevent the user from interacting with the form while a request is in flight. One obvious thing one might want to do after the request is completed is re-focus the form element so the user can continue, say, typing in todo list items.

Without any event after the disabled status is removed, this kind of workflow becomes awkward to implement:

<form
    hx-disable="find input, find button"

    hx-on:htmx:after:request="find('form').reset(), find('find input').disabled = false, find('find input').focus()"
    <!-- or -->
    hx-on:htmx:after:request="find('form').reset(), setTimeout(() => find('find input').focus(), 0)"
    > 

---

It would be nice if there were some event that fired after the elements are re-enabled.

A few ideas:

• Move enableElements call to before the htmx:finally:request event. This would be my preference; IMO "finally" should be fired after all default request behavior is completed.
• Add a new event that fires after all default request behavior is completed. htmx:finallyfinally:request (joke)
• Add hx-disable-specific event(s): htmx:{before,after}:{disable,reenable}. Maybe just htmx:after:reenable

---

Related issue: #3363

[MichaelWest22]

Yeah it is a tricky one. I placed the event just before the indicators and disabled elements are re-enabled at the end because sometimes you need to use this event to set ctx.keepIndicators to false or true here. when you redirect or use hx-location it has to keep the indicators and disabled elements in place so they are stable while you wait for the next page to replace them but if you want to customize things here you might need to disable the keepIndicators in this event to make it work for you. This is the only event that fires in the finally block even if the main action is aborted early and the reason this event exists. Adding a another event just for before enabled use case or having another event for really finially done etc seems confusing and wasteful. We could send indicators and disabled elements as extra data to the event so you can deal with them maybe but this adds more options but complexity as well.

I think the simple settimeout is the most sensible and reliable solution here as you are explicitly saying let the event complete and then wait a moment for the item to be fully rendered and disabled before I try focusing it.

Note that often in this situation where you want to focus an input after the htmx action the swap will have just replaced it and disabled will have no impact here by design but if you are swapping to another target then this may be an issue. Also note that there is a useful feature htmx has which is it respects the autofocus attribute when swapping in inputs and this is really useful to allow you to replace an input from the server during your request or with a targeted hx-partial in your response and htmx will then focus this replaced element with autofocus attribute. This allows nice server driven hypermedia way of driving your application.