Scroll to Fragment Hash seems to be deleted by NextJS #82649
Replies: 3 comments 11 replies
-
|
Ah this one again, let me search some previous discussions I have had about this feature and the browser. It has some quirks IIRC. |
Beta Was this translation helpful? Give feedback.
-
|
Okay, let's do a small deep dive as I did here, #71970 nearly a year ago...
The question we need to answer is, can JavaScript see the Short answer, not through the usual means ~~ new URL(performance.getEntries().find(({ type }) => type === 'navigate').name).hash;IIRC, at some point the client side router does some work with the window.location, where this value is not present, and that's why it ends up getting dropped. I'll be doing some updates/edits to this answer as I refresh my memory. A site like, https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#:~:text=human, also drops the value from the URL. Same with https://en.wikipedia.org/wiki/React_(software)'#:~:text=React%20can%20be%20used%20to We live in a world where a lot of sites use client side routers that when manipulating the history API and such, drop the text fragment, because it is not part of the URL API - I guess you could say, but I found one that's stable: Look at the console I ran: 
So yeah, the performance entries hack still kind of works... but you see, the URL API has no knowledge of it |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, that is shedding a lot of light into the issue and is helping a ton! I will test your workaround and see if that helps! |
Beta Was this translation helpful? Give feedback.
-
|
No worries ~ this is bound to happen with this experimental bits of tech - and the privacy concerns around it. Hope the performance entries hack does the trick. I reckon in TypeScript you can have to make an assertion, like |
Beta Was this translation helpful? Give feedback.
-
|
I can confirm, it works nicely in Chrome, but fails in Firefox and Safari. |
Beta Was this translation helpful? Give feedback.
-
|
My screenshot from the Chromium blog shows that, I think, you can't through the URL api, in window.location - it's just not there.
Idk if there has been changes to that plan, but this is clearly not working now, so there's that. |
Beta Was this translation helpful? Give feedback.
-
// in _document.js
import { Html, Head, Main, NextScript } from 'next/document';
export default function Document() {
return (
<Html>
<Head>
<script dangerouslySetInnerHTML={{
__html: `
(function(){
if (location.href.includes('#:~:text=')) {
localStorage.setItem('textFragment', location.href.split('#:~:text=')[1]);
}
})();
`
}} />
</Head>
<body>
<Main />
<NextScript />
</body>
</Html>
);
}
Key takeawayYou’re not losing the hash because of Next.js — it’s Chrome’s Text Fragment API intentionally removing it before JavaScript runs for security. |
Beta Was this translation helpful? Give feedback.
-
|
Hm, if it was purely Chrome, then why does it not hide it on other sites - for example we have some sub pages running on Wordpress where this does not happen. It is also happening on Firefox (did not test Safari also). But getting the hash saved someplace else might be a workaround. I will try the introduced workarounds and see which will work best. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
It appears that even when inserting it into the document, it is already too late for setting the untouched url aside. I am a bit flabberghasted how the client side router can in any way do that before a script in the very top of head is executed. I also tried out if it makes any difference in _app with beforeInteractive - I only see the href without any hash params. Tested on firefox and chrome. |
Beta Was this translation helpful? Give feedback.
-
|
It is because you are seeing two different things, and not wanting to accept that this experimental feature (text fragments) has some very rough and sharp edges... Once again, if you go to https://blog.chromium.org/2019/12/chrome-80-content-indexing-es-modules.html#:~:text=ECMAScript%20Modules%20in%20Web%20Workers - that page is as simple as it gets - try to do |
Beta Was this translation helpful? Give feedback.
-
|
After really understanding the issue: the fragment hash will never make it to the location api, as icyJoseph said - so it cannot be extracted before. |
Beta Was this translation helpful? Give feedback.
-
|
As for,
Browsers do all sorts of things before scripts run, like modifying incorrect HTML structures, strip away attributes like nonces, etc... |
Beta Was this translation helpful? Give feedback.
-
|
As there is no real solution apart from the hack that only works on Chrome, I am closing this as intended and not solvable. ;aybet it is better that way, as getting that fragment is a bit divulging the user's search terms. |
Beta Was this translation helpful? Give feedback.
-
|
Okay, good luck with your work |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Summary
When applying a text fragment search hash (as done by Google AI search) the search is getting executed, but NextJS seems to remove the hash param from the url.
When calling a hash param to use the scroll to text fragment function by adding "#:~:text=" to the url like http://loclhost:3000#:~:text=FooBar to search for FooBar on the page, highlight it and scroll to it as done by Google's AI Search, the highlighting and scrolling is executed, but next seems to remove the hash from the URL. I would like to track these, but at the time of a useEffect, the data is already gone.
I am using Next 15.3.5 with the page router and have that on three separate installations.
Does anyone know anything about this - or how to circumvent this?
Additional information
Details about the feature:
https://chromestatus.com/feature/4733392803332096
Example
https://strange-animals.photography/#:~:text=impressum
Beta Was this translation helpful? Give feedback.
All reactions