Browser does not change focus to hash fragment given by `Hx-Location` response header

[nmattela]

Hi,

Before creating a PR with a possible fix I have in mind, I first want to know whether this is a bug or a feature.
I am looking to implement a "locate" feature, wherein one can locate (and highlight) an element in a long, paginated list by its id. To achieve this, the user first searches the element by its ID, which sends a request to the server. The server will look up what page the element belongs to, then returns a URL that contains the correct page number as a query parameter. This URL is provided via the Hx-Location header. The server will also add a hash fragment to the URL with the element's ID, so that the browser can then automatically scroll to and highlight that element on the page.
This last part is where there's a problem: HTMX will use history.pushState to push this new URL onto the history stack of the browser, including the hash fragment. However, history.pushState does NOT signal the browser that the hash fragment has changed, and that the browser should focus on the associated element. Other methods such as window.location = "<location given by Hx-Location>" will trigger the change.
Is this behaviour a conscious design decision or not? Cause if not, when hx-push-url or hx-replace-url are set to true, the pushUrlIntoHistory function can be extended by also updating window.location to trigger the hash change.

As a sidenote: this behaviour used to be possible with using the Hx-Redirect response header. However, as of a recent Firefox update, this is no longer possible.

[MichaelWest22]

Yeah this is strange as I think this should just work. Just checked the htmx code and the hx-location does in fact process and set the anchor property and do a scroll into view on the fragment id.

https://jsfiddle.net/Latent22/x7hak4pb/

Here is a quick jsfiddle showing it working with a mocked hx-location response header.

Note that it is not the browser doing the scroll to the anchor it is htmx detecting an anchor and doing a manual scroll which it does on all ajax requests with paths with anchors.

Also did a quick test on firefox with hx-redirect and this worked fine for me as this is just a browser full page load so of course it should just work as it has nothing to do with htmx after the redirect happens in the page.

It may be possible that the id format you are using for your elements is not a valid css selector format which will prevent htmx processing it as it is not valid. numbers at the sart of css selectors are trouble unfortunately.

[MichaelWest22]

also i have #3404 which I'm trying to get merged which extends hx-location to allow setting the push and replace history path manually in the hx-location header and supports using hx-push-url with hx-location in a chain better. tweaking the exact displayed history path and how it replaces or adds to history may give you more options.

For example you could maybe use hx-location path to load the data with the fragment for scrolling but also set replace to return the url to the current or different location with no anchor showing in the address bar.

[nmattela]

Hi Michael, thanks for the jsfiddle which indeed makes the browser jump to the correct location as expected. However, the target that it jumps to is somehow not made queryable using the :target CSS pseudo class which I used to color the targeted element to make it distinguishable. Here is a modified version of your fiddle as an example. According to the CSS, the targeted element should turn its background color purple, but it does not.

[nmattela]

From mdn:

The target element is set at document load and history.back(), history.forward(), and history.go() method calls. But it is not changed when history.pushState() and history.replaceState() methods are called.

Yeah... pushState does not set the element as :target :(

[MichaelWest22]

Yes this is expected sorry. See #3447

For spa style use of push State etc they chose not to alter the page load target in the browser by design. You can add event listener to do it manually it seems if you need this

[nmattela]

Unfortunate, but the fix proposed in the other issue seems to be working.