1753933 - (text-fragments) [meta] Implement Text Fragments (formerly Scroll to Text Fragment)

Status: NEW

(Core :: DOM: Navigation, enhancement)

Description

[Anne (:annevk)]

Specification: https://wicg.github.io/scroll-to-text-fragment/

standards-positions: https://github.com/mozilla/standards-positions/issues/194

(As part of implementing this we should figure out how to move this specification to a proper standards venue and ideally have that sorted before shipping.)

Comment 1

[Kai [:schweinepriester]]

Shipped in Chrome & Safari now:

• https://caniuse.com/url-scroll-to-text-fragment
• https://webkit.org/blog/13399/webkit-features-in-safari-16-1/

Comment 3

[Alexandre Poirot [:ochameau] [PTO back August 21]]

Note that Google Search seems to be using this feature to scroll to precise content from search results:
https://til.simonwillison.net/html/scroll-to-text

Comment 4

[James Teh [:Jamie]]

For accessibility, at a minimum, we need to notify accessibility APIs of the node to which the page has scrolled. See nsAccessibilityService::NotifyOfAnchorJumpTo.

Even with this, significant parts of this feature will be inaccessible:

1. There is no way for an assistive technology user to perceive the exact text which is visually highlighted. They only know about the node in which the text begins.
2. There is no way for an assistive technology user to perceive any text directives other than the first.

We should ideally figure out and implement these before we ship this.

See also https://github.com/WICG/scroll-to-text-fragment/issues/142#issuecomment-1709325246

Comment 5

[Frank]

Any news on the arrival time of this feature?

Comment 6

[Jan Jaeschke [:jjaschke]]

Hi Frank,

thank you for your interest in this feature. While I can not give you an exact arrival time (and I can only speak for the DOM part of this, ie. opening a link that contains a text fragment, not creating a link to a text fragment), I can tell you that we are actively working on this and you can expect this feature to be turned on in Nightly in the next couple weeks / months.

Comment 7

[Frank]

Good evening Jan,

Thanks for the detailed answer!

Comment 8

[Jon S]

Also requested on Connect here: https://connect.mozilla.org/t5/ideas/support-text-fragments/idi-p/21797

Comment 10

[Swudu Susuwu]

(In reply to James Teh [:Jamie] from comment #4)

For accessibility, at a minimum, we need to notify accessibility APIs of the node to which the page has scrolled. See nsAccessibilityService::NotifyOfAnchorJumpTo.

Even with this, significant parts of this feature will be inaccessible:

1. There is no way for an assistive technology user to perceive the exact text which is visually highlighted. They only know about the node in which the text begins.
2. There is no way for an assistive technology user to perceive any text directives other than the first.

We should ideally figure out and implement these before we ship this.

See also https://github.com/WICG/scroll-to-text-fragment/issues/142#issuecomment-1709325246

if(textFragment) {TTS.output("Resource will scroll to first instance of '" + textFragment "'");}

Comment 11

[Swudu Susuwu]

Asof 129.0, Fenix continues to require chrome://geckoview/content/config.xhtml -> dom.text_fragments.enabled=true to do Scroll to Text.
How about desktop Firefox?

Comment 12

[Swudu Susuwu]

Related to https://github.com/orgs/community/discussions/131838 "Line numbers become out-of-date after a few commits; How to reference functions/symbols (scroll-to-text)?"

Comment 13

[Sebastian Zartner [:sebo]]

(In reply to 2002luvabbaluvu from comment #11)

Asof 129.0, Fenix continues to require chrome://geckoview/content/config.xhtml -> dom.text_fragments.enabled=true to do Scroll to Text.
How about desktop Firefox?

This feature didn't ride the trains to release yet. I've just created bug 1914877 for that. Jan, maybe you can add the bugs blocking the release there.

Sebastian

Comment 14

[Jan Jaeschke [:jjaschke]]

I just enabled Text Fragments on all channels, which means that it will be available in the Firefox 131.0 Release cycle.

Comment 15

[firefoxic.dev]

(In reply to Jan Jaeschke [:jjaschke] from comment #14)

I just enabled Text Fragments on all channels, which means that it will be available in the Firefox 131.0 Release cycle.

Hi! How can I try it in the Firefox Nightly? Or is it still early?

Comment 16

[Jan Jaeschke [:jjaschke]]

The feature is enabled in Nightly. Note though that the current state only includes opening a link that contains a text fragment, not creating a link with a text fragment. Therefore, things like a context menu entry to create a link to the selected text are not yet available. This will follow soon-ish though, and you can follow the progress in this meta-bug.

Comment 17

[Sören Hentzschel]

In the meantime, you can use an add-on (for example https://addons.mozilla.org/en-US/firefox/addon/link-to-text-fragment/) or another browser to create such URLs from content, if you don't want to create them manually but already test the feature.

Comment 18

[Jan Jaeschke [:jjaschke]]

Yes, that should work.
The add-on seems to have had problems with actually showing the highlights for some reason, but creating links should be working fine. Thanks for adding this here. :)

Comment 19

[firefoxic.dev]

Yeah, it works 😍
Even without the context menu opening links is already very cool. Thank you!

Comment 21

[Eli Grey (:sephr)]

I believe that https://bugzilla.mozilla.org/show_bug.cgi?id=1919565 was closed without proper follow up comms. The changes merged do more than indicated by the issue title.

Additionally, I understand that my 'only hide the text directive' request requires a spec change but I would have appreciated more coordination and support around not breaking previously supported use cases (e.g. by offering to delay or subset the fix until spec changes can be proposed). Firefox previously didn't strip fragment directives in such a manner that it arguably wasn't a bug prior to Firefox gaining support for scroll-to-text.

Comment 22

[Simon Pieters [:zcorpan]]

I can follow up in that bug.

Comment 23

[Eli Grey (:sephr)]

(In reply to Simon Pieters [:zcorpan] from comment #22)

I can follow up in that bug.

Thanks. Please do so at your earliest convenience.

Comment 24

[Eli Grey (:sephr)]

Oh I see it got a new title. I didn't notice that at first.

Comment 25

[Eli Grey (:sephr)]

(This comment belongs in https://bugzilla.mozilla.org/show_bug.cgi?id=1919565 but the issue has been closed)

Transcend added their config overrides feature long before Firefox added support for scroll-to-text.

It is objectively incorrect to claim that Transcend was relying on a bug in your scroll-to-text implementation given that your implementation did not exist at the time.

I am once again asking for reconsideration on shipping a change to hide fragment directives, as you are introducing a new feature-breaking web incompatibility.

I propose hiding only the text fragment directive.

Comment 26

[Jan Jaeschke [:jjaschke]]

Transcend depends on a bug in the scroll to text fragment specification, which unfortunately is also a bug in the first implementation of the spec, namely Chromium, not on a bug in Gecko.
<edit after some research>The spec is actually pretty clear: Fragment Directives are hidden from script. And the navigation timing entries should return the Document's URI, which must not contain the fragment directive. So, this is clearly a bug in the Chromium implementation and not intentional behavior (despite it being referenced in the text fragment article on web.dev).</edit>

WebKit and Gecko behave correctly. I do not expect Mozilla or Apple to open this loophole up again — instead I expect Chromium folks to close it.

The intention of all fragment directives is to provide user-agent only information. There are other places (e.g. query or fragment of the uri) which are designed to contain state of the web app.

We are aware of your situation and have reviewed your arguments. We offered you an origin trial to allow Transcend to move to a web compatible solution. We are aware that this is not the outcome you prefer and that you likely won’t agree with our position.

If you disagree with the spec (and, for that matter, the bug in the spec), I would suggest moving the discussion there. Spec PRs are always welcome. With respect to the current state of the spec, this decision is final on our end.

Comment 27

[Eli Grey (:sephr)]

I believe that the only responsible path for breaking an existing API is to first collect usage metrics. Did Mozilla ever do this? e.g. you could add instrumentation to check how often fragment directives are present in performance.getEntries() when performance.getEntries() is called.

This change is causing serious problems. Firefox uniquely doesn't support location.ancestorOrigins. We compensated for this in Transcend XDI (our cross-subdomain same-site private consent sync protocol that doesn't use cookies) many years ago by having XDI clients hint their origin to XDI hosts. The way this hint was implemented was via fragment directives.

Now same-site consent sync is broken on many of our customer sites for Firefox users until they can adopt our fix.

This wouldn't have happened if Mozilla implemented fragment directive stripping by only stripping well-known privacy-sensitive directives OR if Firefox supported location.ancestorOrigins.

Comment 28

[Eli Grey (:sephr)]

Also in terms of collecting usage metrics, did you ever collect any metrics on how many navigations contain the fragment directives delimiter?

Comment 29

[Simon Pieters [:zcorpan]]

We don't have use counters for fragment directives currently, but plan to add use counters. We did look for usage by static analysis (httparchive, github code search), which indicated that usage of fragment directives other than text is very rare. Waiting for usage metrics to be collected (needs to wait for shipping) carries some risk also, because new content can start relying on the bug in the meantime.

Thank you for letting us know that support for location.ancestorOrigins (bug 1085214) is needed for your use case.

Comment 30

[Mr. Beedell, Roke Julian Lockhart (RJLB)]

We did look for usage by static analysis (httparchive, github code search), which indicated that usage of fragment directives other than text is very rare.

[e-mail], that can't be correct (if I've understood correctly what you've stated). Every heading implementation I've ever seen utilizes the fragment, including MediaWiki – see wikipedia.org/w/index.php?title=URL&oldid=1230124093#Syntax.

Comment 31

[Jan Jaeschke [:jjaschke]]

Fragment != Fragment Directive. Fragment Directive is a fragment (#…) that contains the string :~:.

Comment 32

[Eli Grey (:sephr)]

A search for (":~:") NOT ("#:~:text") language:html on GitHub currently gives me a top result for what appears to be a site using custom text directive handling for forwarding searches to iframes.

Comment 33

[Will]

Please take a look. I apologize if it's a duplicate https://bugzilla.mozilla.org/show_bug.cgi?id=1945022