1992505 - Gecko's text fragment processor does not follow IETF RFC3986 section 2.4 (which says to allow encoded versions of the tilde such as "%7E"), thus Firefox can not use encoded text fragments from Markdown.

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, enhancement)

Description

[Swudu Susuwu]

Steps to reproduce:

• Browse to web services which allow Markdown.
• Input Markdown references to text fragments (such as [this should scroll to Marker](#:~:text=Marker).
• Once posted, browse to those references.

Actual results:

• Most web services replace ~ with %7E, which browsers do not process but are supposed to. The browser ignores the #* (on both desktops plus smartphones).

Expected results:

• The browser should color instances of Marker, plus scroll down to the first instance of Marker.

Comment 1

[Swudu Susuwu]

Example: this should scroll down to the first instance of Marker.
The Preview tab shows that Bugzilla does not substitute the tilde with %7E: if so, bugzilla.mozilla.org is not affected, but most implementations of Markdown are affected.

Although not all web services require to follow this standard, nothing should break if the standards are followed (if the browser is enhanced to allow substitutions), since #:%7E:text=Marker has no current definition (other than as an alias for #:~:text=Marker).

Comment 2

[Swudu Susuwu]

Attachment: How StackExchange encodes tildes in Markdown references as `%7E`.

Example of web services which require browsers to follow tilde substitutions.

Comment 3

[Jan Jaeschke [:jjaschke]]

Hi, thanks for bringing this to my radar!

I don't think this is a bug in the browser engines. Note that the concept of a fragment directive does not exist in the IETF spec, only in the HTML spec (so, currently, the Text Fragments WICG spec). The Text Fragments spec defines the fragment directive identifier as :~:, which is not percent-encoded.

Although not all web services require to follow this standard, nothing should break if the standards are followed (if the browser is enhanced to allow substitutions), since #:%7E:text=Marker has no current definition (other than as an alias for #:~:text=Marker).

I disagree. Let's say a web page has anchors in its html that look like this: id=":~:text=foo" as some sort of polyfill for text fragments. A user agent which does not support text fragments would load example.com/#:~:text=foo and example.com/#:%7E:text=foo (and, presumably, example.com/#%3A%7E%3Atext%3Dfoo) interchangeably -- it would scroll to the anchor :~:text=foo.
However, a user agent which supports text fragments would invoke the text fragments algorithm for example.com/#:~:text=foo, which scrolls to and highlights the first occurrence of foo in the document, and scroll to the anchor :~:text=foo when loading example.com/#:%7E:text=foo. This is clearly different behavior.

The discussions on stackexchange took place under the premise that the feature is Chrome-only and not specified. Both of these assumptions are false (the WICG spec existed back in 2022, and text fragments are supported in Chrome, Safari and Firefox nowadays).

Furthermore, as you noticed in comment 1, this is not an issue in markdown processing in general, but in one particular implementation (note that text fragment links also work as expected for example in Github). The comments in the post you posted show that stackexchange seems to have other issues regarding how the tilde is processed (or, FWIW, the asterisk). While I'm all for "being pragmatic and making things work", this is pretty clearly an issue on their end.

Additionally, this would have to be changed on a spec level, therefore the right place to raise this would be here.

Hence, closing as invalid until there is a spec-level solution.