Do not remove pre-existent `#.*:` section of URI.
Closed this issue · 3 comments
If I use the extension on https://www.myheritage.com/FP/memberEditProfile.php?s=781598791&memberID=1085838471&sourceList=#notificationPanelAnchor:~:text=I%20am%20researching%3A-,my%20email%20,-Email%3A at https://www.myheritage.com/FP/memberEditProfile.php?s=781598791&memberID=1085838471&sourceList=#notificationPanelAnchor, notificationPanelAnchor is removed, resulting in https://www.myheritage.com/FP/memberEditProfile.php?s=781598791&memberID=1085838471&sourceList=#:~:text=I%20am%20researching%3A-,my%20email%20,-Email%3A.
This is erroneous, because that part of the URI has meaning, especially in circumstances where it isn't simply used to communicate where scroll the page to. However, in the instances that it is, such as at https://en.wikipedia.org/wiki/Allied_invasion_of_Italy#Salerno_landings, it is a useful fallback for browsers where fragment support is unavailable.
This has been discussed in WICG/scroll-to-text-fragment#75. The spec also has a section about this question. There are two cases: the first case is the one where the page actually has an element with the hash ID, like <h1 id="example">Example</h1>, and the second case it the one where the hash is used as a JavaScript-based router, but doesn't appear in the page, like https://example.com/#page1. Your example seems to be the latter, in which case "If the UA cannot reliably determine an appropriate fragment to fallback to, it should remove the fragment id from the URL" kicks in.
@tomayac, WICG/scroll-to-text-fragment#75 (comment) discusses the behaviour of the search functionality when the fragment is included with the directive. I don't care about that; I just want this extension to not remove that portion because it causes issues when the fragment isn't used for searching the page. Fragments are frequently used for other purposes, so they're as important a part of any URI as any other.
WICG/scroll-to-text-fragment#75 (comment) states
The fragment still serves as a fallback with the current design (we scroll to the fragment ID if we can't find the text directive)
so I'm extra confused by why keeping the fragment included isn't desirable.
Just submitted v2.4.0 to the store that preserves potentially existing hashes.