Do not run window.history.replaceState unconditionally

[haampie]

Closes #13916

Currently every Sphinx documentation page always drops #:~:text=... Text Fragments due to an unconditional window.history.replaceState() call. That replaceState() is almost always redundant, since it happens when handling ?highlight=... search term highlighting, which is rarely present in the URL.

It's undesirable, because it prevents users from sharing the URL verbatim including the text fragment from the browser's URL bar. Text fragments are increasingly popular these days as they're used by Google Search and various LLMs to scroll to and highlight specific content on a longer page.

The solution is to only call window.history.replaceState when a Sphinx's custom ?highlight=... search param is part of the URL.

[jayaddison]

For this pull request and/or #13921, please add an entry in the CHANGES.rst file -- perhaps at the end of either the bugfix list or features list, as appropriate, with a description of the modifications and a credit entry.

[haampie]

@jayaddison, I've added it to CHANGES.rst.

Since #13921 seems to be blocked, I'd suggest to go with this minimal bug fix.

Is the CI failure expected? Looks unrelated.

[jayaddison]

@haampie thanks for being patient - this looks good to me, and I have tested it locally to confirm the before-and-after behaviours.

I agree that the 1-out-of-30 GitHub Actions check failure (unit tests) seems to be an unrelated issue - we'd welcome a bug report (similar to #12159 for example) if you have time -- I'll try to get around to reporting that within the next week or so otherwise.

[haampie]

Looks like an issue was already opened a couple weeks ago: #13996

[haampie]

@jayaddison closed and opened the PR to restart github actions, which are now green. So the PR should be good to go.

[jayaddison]

Thanks @haampie - I'm a contributor here, but I am not a core developer/maintainer, so I don't have permissions to merge. We'll need to wait/find one of the core team to help with that (they do check recently opened PRs from time to time; I can't guarantee how long it may take, though).

[haampie]

Maybe a friendly ping to @mgeier helps? For context, this PR should not be controversial, in contrast to #13921.

It fixes a bug where the browser clears parts #... bit of the URL on page load, even if there is no ?highlight=... param. Now it only does that when there is a highlight param.

[mgeier]

I'm not a core dev either. I approve, but someone else will have to merge it.

[haampie]

In that case a friendly ping for @AA-Turner for a potential merge, since this PR has fallen of the first PRs page.

[AA-Turner]

Please can you add a comment explaining why we don't unconditionally run the code. If possible, adding a test would also be great.

A

[haampie]

I've added a comment, which I think is enough. There are no existing tests covering that part.

[AA-Turner]

Thanks!

A