Fix relative resource URLs for boosted links

[danpalmer]

Relative resource URLs on boosted pages don't work. The order of operations is:

1. XHR request is made for new content
2. Content is swapped
3. Browser evaluates new content, loading resources
4. URL is updated

This means that relative URLs are evaluated in the context of the previous page. The correct order of operations should be:

1. XHR request is made for new content
2. URL is updated
3. Content is swapped
4. Browser evaluates new content, loading resources from URLs relative to requested URL.

This PR aims to resolve this issue. As history is disabled in the unit tests I think it's impossible to write an automated test for this change, so I've written a manual test. I've confirmed that the manual test fails without the change and succeeds after it.

---

I have not done a full manual test run myself as I'm not sure of the exact setup for doing so and don't have a range of browsers available. Also there are missing manual tests in the index and it's unclear if this intentional or if they are a little unmaintained? Any advice here would be appreciated.

[danpalmer]

@1cg please have a look and let me know any feedback you'd like incorporated, or any risks of this. I'm new to HTMX and hit this roadblock early on so I may have missed ways in which this breaks other functionality. Hopefully we can get a fix for this issue merged soon though!

[danpalmer]

Hey, friendly ping on this 😄 . Let me know if there's anything I can do to help get a fix for this issue shipped.

[1cg]

Hi Dan, sorry for the delay on this. History is one of the touchiest parts of htmx, so I'm going to need to spend some time w/ the PR to get comfortable w/ it.

Thank you!

[danpalmer]

@1cg thanks, I understand. While I don't want to hurry things, this does feel like a major bug/regression, and while I can imagine this fix being incomplete in some way that I haven't realised, I hope the bug is clear and obvious – that history must be changed after the page content swap?

[1cg]

Hey Dan, do you mean to say that the page URL must be updated before the content swap?

[1cg]

OK, spent some time looking at the code and this is less dangerous than it looked at first and i agree it is the correct behavior

[danpalmer]

Sorry didn't see this when it happened, but thanks for the review and merge!