Spec issue: https://github.com/WICG/scroll-to-text-fragment/issues/223
Demo: https://text-fragment-navigation-timing.glitch.me/#:~:text=Filler%20text

performance.getEntries().find(({entryType})=>entryType==='navigation').name

In Firefox this returns the document URL including the fragment directives. Chrome does so also, but Safari 18 (or at least Safari TP 203 which is what I tested) does not.

I think we should match Safari here and hide the fragment directives. Some way for pages to access fragment directives should first be standardized if there's a need to expose it and if it's OK to do so for user privacy.

The issue title says "Hide the text fragment from Navigation Timing API" but your issue body text references hiding all fragment directives.

Is the intention to hide the text fragment or all fragment directives?

Note that custom fragment directive access is used in production by quite a few sites as a config surface for pseudo-UA tools. Removing all directives could cause compatibility issues with these sites.

It should be consistent with what happens for location.href in my opinion (which hides all fragment directives currently). It seems reasonable to me to only hide text directives, but that would need a spec change: https://wicg.github.io/scroll-to-text-fragment/#remove-the-fragment-directive

Do you know which sites in particular are affected?

This proposed change may be particularly problematic for LG.com, which uses Transcend Consent Management's config overrides feature in such a way that relies on this non-URL-stripping behavior, to deep-link to specific privacy interfaces in their policies. There are potentially other sites with similar limitations. If Transcend changes their implementation to support an alternative API, customers would still have to update their code.

This fragment directive access technique worked in Firefox, Chrome, Edge, and Safari for multiple years now until Safari's recent announcement to change their behavior in Safari 18.

All Transcend Consent Management customers (won't enumerate, but this includes sites in the top 50 most visited websites according to https://www.semrush.com/blog/most-visited-websites/) are affected by this proposed change to some degree. Transcend Consent Management's config overrides feature is primarily used and positioned for testing limited configurable parameters of Transcend's Consent Management product, though customers are not restricted from using this feature in more significant ways with potential for breakage. I haven't checked amongst Transcend customers, but I wouldn't be surprised if one or more customers are using this feature to force an inferred privacy legal regime for specific website flows.

Transcend intends to adopt future APIs that provide fragment directive access (e.g. my proposal) when available, and in the meantime, I am advocating for a transition period where the current behavior is preserved until a new fragment directive access API is available.

Additionally, I consider the suggested privacy considerations of the text directive to be tenuous, as search text or rough search intent can still be extracted even when fragment directives are stripped from all URL interfaces. Un-mitigable CSS+JS tricks (such as making text initially extremely large, calculating scroll position, restoring text size, then feeding this position to an AI model) can determine rough search intent.

It is my understanding that hiding fragment directives was originally done more for compatibility than privacy, although the privacy aspects were considered as well. It makes sense that websites should be able to implement custom scroll-to-text (or more broadly 'navigate-to-target') algorithms, e.g. to support scroll-to-text in canvas UIs.

To be fair, this fragment directive exposure behavior started to require a reload in some Safari 17.x version (can't recall the exact version), and later reverted to not requiring a reload afaict. Meaning, you would need to reload the current page for the fragment directives to become exposed in the Navigation Timing API in some 17.x versions of Safari.

I should also note that Transcend does not use the 'text' directive, so only stripping the text directive would prevent breakage at least for Transcend's uses. I am not aware of any sites that use this technique for custom scroll-to-text logic.

If nobody is relying on access to the 'text' directive for legitimate reasons (obviously trackers have some illegitimate reasons here) such as custom scroll-to-text, then I believe that it makes sense to strip the text directive for now. It can later be re-exposed through a purpose-built API for site owners.

Thanks. What Transcend does relies on a known browser bug. I believe the original intent was to hide the entire fragment directive like in document.URL. I would suggest using the fragment or the query instead of custom fragment directives.

Transcend uses custom directives specifically for the hiding effect to prevent interference with fragment-based routing. Additionally, Transcend cannot update existing sites using this functionality. At best they can only reach out to their customers to update their site.

Note that not stripping these directives was not a Firefox bug when Transcend first implemented this, as Firefox didn't implement scroll-to-text, and thus did not strip fragment directives.

Transcend added this feature shortly after Chrome shipped scroll-to-text, before any other browsers had adopted it.

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

I would suggest using the fragment or the query instead of custom fragment directives.

This is not possible for Transcend to fix in a short timeline for sites outside of their control. Transcend licenses software to others, and doesn't control the deployment end-state.

@zcorpan: Please either edit the title of this issue to "Hide fragment directives from Navigation Timing API" or change the proposed patch to reflect the current title.

https://hg.mozilla.org/mozilla-central/rev/9b99c2cfd2dc

:sephr, I've updated the bug title. As noted in the issue description, the intent was to match Safari and the spec (https://wicg.github.io/scroll-to-text-fragment/#remove-the-fragment-directive).

If you rely on a bug being present in a new feature, it shouldn't come as a surprise that it breaks when the new feature is implemented per spec. It's unfortunate that Transcend's clients are affected, but we're not planning to revert this bug fix.

What we could do is implement a temporary origin trial for sites to opt in to the old behavior (but only with the HTTP header). Please let us know if that would be helpful.

The patch landed in nightly and beta is affected.
:farre, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox132 to wontfix.

For more information, please visit BugBot documentation.

FYI MDN docs for this can be tracked in https://github.com/mdn/content/issues/36546. I think only a release note and browser compatibility data note are required.

EDIT: Decided not to do a compatibility update, since this is a bug, and we usually don't track bugs. Did do a release note, and updated the docs for the name to indicate the URL omits text fragments / fragment directives.