Absolute path url arguments do not get merged with current domain before passing through to share targets in fallback mode

[josefdlange]

I'm honestly not sure if this is documented behavior of the Web Share API but I'm seeing diverging behavior in this instance:

1. Call navigator.share with the url argument as a /-prefixed path, like /articles/123/
2. Native navigator.share interprets that into <protocol>://<current-domain-and-port>/articles/123/ when passing through to share target. Kind of how the href of an <a> element is understood correctly when it's just /articles/123/.
3. Polyfill fallback behavior does not do this and just passes through /articles/123/ as the "URL" to any share target.

I'm happy to work on this as a PR to this project but wanted to propose it first and get approval before investing the work.

[valentinoli]

It could be done very simplisticly by checking if the first character of url is the forward slash. If it is, then prepend window.location.origin to the given url. That would be consistent with the native Share API.

I think the native Share API throws an error when only the host is given without the protocol, i.e. example.com/articles/123 throws an error whereas https://example.com/articles/123 does not. So the polyfill should ideally throw an error in the case of a host without a protocol.

if (url.startsWith('/')) {
  url = `${window.location.origin}${url}`
} else if (!url.startsWith('http')) {
  // throw error
}

[josefdlange]

Sounds good. Happy to push a PR with that in a bit here. Thanks for getting back to me!

[valentinoli]

As you said yourself, I'm also not sure if this is documented behavior. I tested it on the new chromium-based Edge desktop browser. There, the protocol and host are prepended to absolute paths starting with /.