Answer links from search pages do not load the page at the linked answer

Question

This appears to have started breaking in the last four hours or so.

To reproduce:

• Do a search for answers on a Stack Exchange site. For the sake of a demonstration I'll use is:a on Meta Stack Exchange. It also applies to Stack Overflow - and I imagine all Stack Exchange sites.

• Click one of the linked answers.

What happens:

• The search correctly displays answers, but the links do not take the page directly to the answer and instead just shows the question.

Taking the answer (post id 342059) to Thank you, Shog9 (the highest-voted answer on Meta Stack Exchange at the moment and therefore the top of the linked search), the URL from the search page is

• https://meta.stackexchange.com/questions/342031/thank-you-shog9/342059?r=SearchResults&s=1|0.0000#342059

which, should go to the <a name="342059"></a> part of the page (i.e. directly to the answer) because it ends with a URI fragment (#342059).

It does not - instead the URL of the loaded page is (note the dangling ? at the end and no fragment identifier (#) at all):

• https://meta.stackexchange.com/questions/342031/thank-you-shog9/342059?

---

This appears to be due to the query string (?) interacting with the fragment identifier. Extracting the characters from the ? to the #, i.e. ?r=SearchResults&s=1|0.0000 to get the URL:

• https://meta.stackexchange.com/questions/342031/thank-you-shog9/342059#342059

does work - as expected. Note that this is exactly the same URL that the link to the answer from Shog9's profile page points to (i.e. without the query).

The URLs are broken whichever query fields are in there (either r or s) but when I replace the r and s fields with anything else (e.g. ?works=true) to get

• https://meta.stackexchange.com/questions/342031/thank-you-shog9/342059?works=true#342059

it does work. It's like the presence of the r and s fields in the query is breaking it. The meanings of the r and s fields are explained in this answer by Glorfindel to Documentation for Stack Exchange engine URLs?:

Questions

• Canonical form: /questions/[question ID]/[question title]
  • Parameters (here is an extended but not up-to-date list, these are the ones I see the most):
    • r=SearchResults: visited from a search results page. In this case, a parameter s=[rank]|[relevance] is added as well; see here for more details.

Note that the presence of the pipe in the s field doesn't seem to be the culprit since

• https://meta.stackexchange.com/questions/342031/thank-you-shog9/342059?fieldwithpipe=1|2|3&fieldwithoutpipe=xyz#342059

works.

Reproduced on

• { Firefox 84.0.2, Chrome 84.0.4147.89, Edge 85.0.564.67 } on Windows 10,
• Chrome 87.0.4280.141 on Android 11

both logged in and with private browsing.

---

This may or may not be related:

For some reason, the URL of the answer changes to add the relevance points (the s field in the query) when I interact with it in the browser. When I hover over it it's

• https://meta.stackexchange.com/questions/342031/thank-you-shog9/342059?r=SearchResults#342059

but when I mouse-down (either left or right button) on the link it changes to add another field (s) - adding &s=1|0.0000 () to the URL:

• https://meta.stackexchange.com/questions/342031/thank-you-shog9/342059?r=SearchResults&s=1|0.0000#342059

This is reflected in the source, which dynamically changes from

<a href="/questions/342031/thank-you-shog9/342059?r=SearchResults#342059"
    data-searchsession="/questions/342031/thank-you-shog9/342059?r=SearchResults&amp;s=1|0.0000#342059"
    title="Thank you, Shog9"
    class="question-hyperlink">A: Thank you, Shog9
</a>

to

<a href="/questions/342031/thank-you-shog9/342059?r=SearchResults&amp;s=1|0.0000#342059"
    data-searchsession="/questions/342031/thank-you-shog9/342059?r=SearchResults&amp;s=1|0.0000#342059"
    title="Thank you, Shog9"
    class="question-hyperlink">A: Thank you, Shog9
</a>

Weird(?)

Answer 1

Good catch, thanks for bringing this up!

The problem was that the #<answer-id> fragment was stripped from the URL after a recent change to our JavaScript. That was not intended and we didn't catch it before shipping and probably wouldn't have spotted this for a good while since this is a rather subtle issue.

A fix is going out as I write this and should land within the next 30 minutes (edit: it's taking a bit longer, I'm on it fix just landed)