Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix relative URLs to be considered as sameHost #3113

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

FeliciousX
Copy link

Description

when the URL function is not used for the URL validation and the path is a relative URL
startsWith(path, document.location.origin) would return false.

Since we can guarantee that relative URLs must be on the same host, I wanted to move the check earlier up the code and return early but unsure if it is a desired pattern.

Corresponding issue:

Testing

We had a site that was working normally but somehow a GoogleTagManager JS that we have no control over was removing the native URL function from the browser (which is wild)

Was implementing a workaround on our end but I thought this might break on IE11 right now if URL is really not available.

Checklist

  • I have read the contribution guidelines
  • I have targeted this PR against the correct branch (master for website changes, dev for
    source changes)
  • This is either a bugfix, a documentation update, or a new feature that has been explicitly
    approved via an issue
  • I ran the test suite locally (npm run test) and verified that it succeeded

when the URL function is not used for the URL validation
and the path is a relative URL
`startsWith(path, document.location.origin)` would return false
@MichaelWest22
Copy link
Contributor

MichaelWest22 commented Jan 9, 2025

Hi FeliciousX,

yeah its crazy that they would break a core JS feature like URL(). This is likely to be just a bug in GTM or a mis configuration somehow. They may be trying to replace the URL() function with their own wrapper so they can track what URL's are being processed inside the page so they can be logged and reported on. It is likely that google tag manager script you have added to your page is actually not working properly anymore after some htmx action. HTMX with features like hx-boost and many of the ways it can replace the body during full page replacement and history navigation can cause problems with some browser features and JS. You can check the GTM script is stable in your head tag as its possible this script is replacing the URL and then getting removed from Head somehow. The htmx head-support extension might help your issue and I would also try setting htmx.config.historyCacheSize=0 and htmx.config.refreshOnHistoryMiss=true so it performs full page reloads each back navigation so it will reload the URL() and GTM scripts each time. I would also recommend loading up browser dev tools and adding a watch in the sources tab for 'URL' and then keep an eye on this as you perform various page navigation actions till you track down the action that breaks the function.

The issue with this fix is that htmx 2.x has fully dropped support for IE 11 so this URL fallback is no longer likely to be maintained and may be removed soon. It could make sense to fix this in the htmx v1 branch instead of dev maybe where IE11 is still supported? would be great to have a test reproduce the issue. It may be that because v1 does not block remote requests by default like v2 the IE bug you found was not picked up?

edit: https://htmx.org/extensions/head-support/ has hx-preserve tag you can use if you install this extension which may help if you place this tag on the GTM script tag maybe.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants