Bug 250317 – Fragment identifiers should be applied to canonical URL when sharing, bookmarking

• Status: NEW
• Component: New Bugs

[Dan]

In iOS Safari, sharing or bookmarking a web page that for which there exists a Canonical Link, generally defined via the <link rel='canonical' href='...'> HTML element, the canonical URL is used instead of the actual URL. Whether or not using the canonical URL for these purposes is appropriate is beyond the scope of this report, as there are benefits, drawbacks and limitations to the approach, and no straightforward alternative I'm aware of. 

Since fragment identifiers are a client-only feature that is reproduced in the canonical URL, any page defining a <link rel='canonical'> effectively prevents iOS Safari users from sharing links that point to specific elements (#id) or text (#:~:text=), as these gets stripped from the shared URL.

The issue affects a vast proportion of websites (more than half of pages analyzed according to HTTP Archive's Web Almanac 2022), e.g.:

https://en.wikipedia.org/wiki/Canonical_link_element#Examples

Behavior of other mobile browsers:

* Firefox Android: shares original URL
* Samsung Internet: shares original URL
* Chrome Android: shares canonical URL, but maintains fragment identifiers

iOS Safari should at least transfer the fragment identifiers to the canonical URL before sharing/bookmarking.

[Dan]

Apologies for typos and unclear prose. The second paragraph should have read:

"Since fragment identifiers are a client-only feature that is *not* reproduced in the canonical URL,..."

The link to Wikipedia was meant to illustrate document fragment usage on a high-profile website that uses <link rel=canonical>. Opening the link in iOS Safari and using the share panel, the fragment is lost.

Finally, "iOS Safari should at least transfer the fragment..." was meant to be followed by "if not renounce sharing canonical URLs altogether".

[Radar WebKit Bug Importer]

<rdar://problem/104296566>