Hash changes are reported on the wrong URL

[Kilian]

Describe the Bug

If you have a page that updates the URL's hash value, those URL changes are reported on the top level / rather than the page itself.

For example, https://polypane.app/css-specificity-calculator/ will append e.g. #selector=header%20h1%23sitetitle%20%3E%20.logo depending on the value added to the input field on that page.

All of these show up as top level links:

Database

PostgreSQL

Relevant log output

n/a

Which Umami version are you using? (if relevant)

No response

Which browser are you using? (if relevant)

all

How are you deploying your application? (if relevant)

node on vps

[mikecao]

I think I know what's going on. We hook into the history.pushState method which passes the changed url. However it looks like it doesn't pass the entire url but just the fragment.

You can try this, edit the tracker/index.js file and change

  const handlePush = (state, title, url) => {
    if (!url) return;

    currentRef = currentUrl;
    // currentUrl = parseURL(url.toString());
    // change to this
    currentUrl = parseURL(location.href);

    if (currentUrl !== currentRef) {
      setTimeout(track, delayDuration);
    }
  };

Then run yarn build-tracker. Let me know if this works for you.

[Kilian]

Right, so what you'll want to do is this:

currentUrl = new URL(url, location.href).href;

This will use the built-in URL API to resolve a potentially relative URL against the current document and then .href will return the combined full url.

I also looked at the parseURL implementation and using origin is wrong, because links can be one of three types, The following links all resolve to the same page:

• fully specified: https://example.com/foo/bar
• relative to the root: /foo/bar
• relative to the current page: ../bar when you're on https://example.com/foo/baz

Using origin will fail the last case.

edit actually it's that very origin causing the issue here.

[Kilian]

Fixed with the above PR