Websites where text fragment link does not work despite text being there and link syntax well formed

[porg]

Operating System in all tests:

• macOS 11.7.10

https://eshop.macsales.com/guides/Mac_OS_X_Compatibility#:~:text=MacBook%20Pro

• ❌ Safari 16.6.1 — No highlighting, no jumping.
• ✅ Chrome 122.0.6261.112

https://eshop.macsales.com/guides/Mac_OS_X_Compatibility#:~:text=MacBook

• ❌ Safari 16.6.1 — ... same situation for match without whitespace.
• ✅ 122.0.6261.112

https://dortania.github.io/OpenCore-Legacy-Patcher/MODELS.html#:~:text=MacBookPro13

• Note: Selected text is quite nested. A code block in a table cell. Maybe the reason why both browsers fail?

  #app > div.theme-container > main > div.theme-succinct-content.content__default > table:nth-child(12) > tbody > tr:nth-child(20) > td:nth-child(2) > code

• ❌ Chrome 122.0.6261.112 — Redirects to URL with entire anchor link including hash symbol all cut off.
• ❌ Safari 16.6.1 — Redirects to URL with hash still there, and everything behind cut off.

https://dortania.github.io/OpenCore-Legacy-Patcher/MODELS.html#:~:text=below%20tables

• Note: This is text in a <p>, so seemingly easy to select at least for Chrome:

  #app > div.theme-container > main > div.theme-succinct-content.content__default > p:nth-child(4)

• ✅ Chrome 122.0.6261.112 - Text highlighted and jumped to (on mini height viewport).
• ❌ Safari 16.6.1 — Redirects to URL with entire anchor link including hash symbol all cut off.

https://dortania.github.io/OpenCore-Legacy-Patcher/MODELS.html#:~:text=verified%20your%20hardware

• Note: This is text in an <a> within an <h1 with an id>.

  #app > div.theme-container > main > div.theme-succinct-content.content__default > h1:nth-child(21) which has #once-you-ve-verified-your-hardware-is-supported-head-to-download-and-build-macos-installers > a.header-anchor

  • ✅ Chrome 122.0.6261.112 — Text highlighted and jumped to (at the bottom of long page).
  • ❌ Safari 16.6.1 — Redirects to URL with entire anchor link including hash symbol all cut off.

https://dortania.github.io/OpenCore-Legacy-Patcher/MODELS.html#macbook-pro:~:text=MacBookPro9

• Note: An existing anchor link + a fragment link.
  • User expectation (not knowing spec honestly): Try fragment link, else fall back to anchor link, else fall back to base URL.
• 🆗 Chrome 122.0.6261.112
  • ❓ Ignores text fragment and instead redirects to anchor link .../MODELS.html#macbook-pro visibly in the OmniBar
  • ✅ Jumps viewport so that headline right below top menu bar of website.
• ❌ Safari 16.6.1
  • ❓ Ignores text fragment and instead redirects to anchor link .../MODELS.html#macbook-pro visibly in the address bar
  • ❌ Jumps not to anchor at all, but somewhere completely else
  • Seems to jump to recently scrolled position instead (seemingly still in memory!).
  • When I opened that URL in an anonymous window which had no history:
  • ❓ Ignores text fragment and instead redirects to anchor link .../MODELS.html#macbook-pro visibly in the OmniBar
  • ✅ Jumps viewport so that headline right below top menu bar of website.
  • Could reproduce this only twice!
  • Found no way to reset this somehow persisted scroll position reliably:
    • Cleaning browser history, nope.
    • Quitting Safari, and open new anonymous window (slightly resized in some test variants). Sometimes same weird jump position. Sometimes jumps viewport so that headline right below top menu bar of website.

https://support.apple.com/en-us/108052#:~:text=2016

• Note: This is text in a <h2> without an id.

  #sections > h2:nth-child(176)

• ✅ Safari 16.6.1
• ✅ Chrome 122.0.6261.129

https://support.apple.com/108052#:~:text=2016

• Note 1: This is text in a <h2> without an id, exactly as in the URL before.
• Note 2: There is a HTTP 302 redirection.
  • from the language neutral URL: https://support.apple.com/108052
  • to a language specific URL: https://support.apple.com/en-us/108052
  • and the fragment link survives this well
• ✅ Safari 16.6.1
• ✅ Chrome 122.0.6261.129

https://support.apple.com/en-us/108052#:~:text=MacBookPro13

• Initial challenge: I wanted to link to the text portion MacBookPro13,3 but the comma in the value of the query string possibly has a special delimiter meaning. So I search for MacBookPro13 which yields 3 results on that page: A MacBookPro13,3, a MacBookPro13,2 and last a MacBookPro13,1, and the first result is my intended target MacBookPro13,3 anyhow, so good enough to keep it simple.
• Note 1: This is text in a <p> with a class.

  #sections > p:nth-child(180)

• Note 2: On the very same webpage, the fragment link to 2016 in an <h2> works in both browsers (see previous test record) but on the other hand MacBookPro13 in a <p> then fails in both browsers. Any ideas why?
• ❌ Safari 16.6.1
• ❌ Chrome 122.0.6261.129

[porg]

Added 3 new use cases above:

• ✅ https://support.apple.com/108052#:~:text=2016
• ✅ https://support.apple.com/en-us/108052#:~:text=2016
• ❌ https://support.apple.com/en-us/108052#:~:text=MacBookPro13

I'd appreciate a reaction to my report! Thanks!

[porg]

No reaction? Please!

[bokand]

Sorry! Thanks for the ping - this has been sitting in my TODO list, I'll take a look today.

[bokand]

Thank you for the details!

https://dortania.github.io/OpenCore-Legacy-Patcher/MODELS.html#:~:text=MacBookPro13

This is due to the word bounding restriction, we treat "MacBookPro13,1" as the full word. To select this you'd need: :~:text=MacBooPro%2C1

❌ Safari 16.6.1 — Redirects to URL with hash still there, and everything behind cut off.

Yeah, looks like the page resets fragments from JS - guessing the timing of when that's read differs between Safari and Chrome. I think this is specified to happen before the page should have a chance to run JS so I suspect Safari's implementation does it elsewhere.

https://dortania.github.io/OpenCore-Legacy-Patcher/MODELS.html#macbook-pro:~:text=MacBookPro9

This is the same issue as the one on the top - we can't find the "MacBookPro9" instance since we'd need to look for "MacBookPro9,1". However, the fragment is found so is scrolled to as expected (i.e. equivalent to navigating to #macbook-pro).

https://support.apple.com/en-us/108052#:~:text=MacBookPro13

Similarly, to select MacBookPro13,3 use: text=MacBookPro13%2C3.

[porg]

• Thanks for explaining some of the observed phenomena.
  • I now realize that only whole words can be linked to (no partial matches at start mid or end of a word) which makes very much sense for stable fragment links.
  • JS intervention different in Safari - Shall/is this filed at Apple / WebKit?
• Please also address the other reported phenomena.

[bokand]

JS intervention different in Safari - Shall/is this filed at Apple / WebKit?

I'm not sure - feel free to file a bug with WebKit: https://webkit.org/reporting-bugs/

Please also address the other reported phenomena.

Sorry, I thought my explanation applies to all the failing cases mentioned (i.e. all cases where the highlight fails, the whole word requirement is the root cause). Was there a specific case that's not answered by the above?

[porg]

Yet unaddressed phenomenon

https://eshop.macsales.com/guides/Mac_OS_X_Compatibility#:~:text=MacBook https://eshop.macsales.com/guides/Mac_OS_X_Compatibility#:~:text=MacBook%20Pro

• ❌ Both fail in Safari. ✅ Both work in Chrome.

Praise — Fragment link survives server side HTTP 3xx redirection just fine

https://support.apple.com/108052#:~:text=2016

• ✅ Works both in Safari and Chrome. Was positively surprised!
• 💡 Feedback: The spec currently only has a few side mentions on terms related to server side HTTP redirections.
  • It's fine that this interplay "just works" in browsers that I tested.
  • But that should not be left up to luck, but should be specced explicitly IMHO.
  • Note though: As a UX designer I spec interactive product behavior. But not technical standards. So I'm a layman in that regard! Possibly the behavior of how browsers handle server side HTTTP redirects is so clear and unambiguous there's not doubt how it should interplay with the local redirection mechanisms, and therefore NOT mentioned at all. I just raised attention for this it to be sure nothing was forgotten in that regard.

[bokand]

❌ Both fail in Safari.

I don't see any obvious reason why it shouldn't work, per spec. The fact it works in Chrome makes me think this is likely a bug in WebKit and I'm not able to root cause that. Your best bet is probably to file a bug with WebKit.

But that should not be left up to luck, but should be specced explicitly IMHO.

It's definitely not luck :) This took quite a bit of effort (it even works across client-side redirects, at least in Chrome) and is specified by virtue of the user activation being part of the navigation request which is preserved (along with the fragment in the URL) across navigation redirects.

[porg]

Ad 1) Am on Safari 16.x. Will re-check this on v17.x when getting a newer Mac and then file if needed.

Ad 2) Glad that this is specced explicitly. As a less technical reader I could not grasp what it deals with on first sight. I had searched for "HTTP redirect", "HTTP 3" as in "3xx", then "redirect" and finally found that section. On first glance of that section I was not sure that it indeed deals with the interplay of server side and local redirects. But I assume a real technical reader realizes that quicker hopefully.

[porg]

So from my side we can close this issue, the spec seems to cover all phenomena, and I just found browser mis-implementations.

[bokand]

Thanks for the detailed investigation!