Its needed if the "remember selected namespaces" checkbox is selected. We should use js to remove it if that box is not set.

I misunderstood this bug. Appearently we have js code that uses html5 history api to inject the search csrf token into the addressbar. Which seems very silly. Sorry, I made a lot of assumptions about this bug that was wrong. My bad. I was confusing with nsRemember field.

In particular it looks like this is implemented by src/mediawiki.action/mediawiki.action.view.redirect.js redirecting to the "canonical" URL.

Afaik: This token is not a csrf token and not added by MediaWiki core redirect handling.

Rather, it’s added by WikimediaEvents for use during EventLogging campaigns. I agree that it should be proactively hidden from users. It is generated on pageload (if missing) and all added to clicked links as well. But there should be no need to add it to the current url when missing. And when found, after clicking a link, we should remember to hide it on page load as well (after storing it in memory).

We’ve done the same in the past with similar campaigns so this isn’t a new issue. We’ve solved it before already.

This searchToken is primarily used to associate search requests with clicks on those search result pages. The token itself is a random string that is inserted into a log message created when a user performs a search. We then join the search logs with the web request logs to generate click logs. These click logs are fed into the machine learning system that ranks search results. It is certainly not the best way, and we can discuss what might be a better way.

Some notes:

• Additional query parameters can not be added to search result urls, as that would bypass caching. There is a special wprov query parameter that varnish ignores but it doesn't seem to fit well here.
• Instead the token is added to the URL of the search result page. Any link clicked then sends this token in the referrer header. This gives the direct connection between individual search events and what links were clicked
• Other sites implement this as a redirect bounce. We could certainly do that but it seemed more performant to not make the extra round trip to record clicks.
• We've evaluated using sendBeacon on clicks to record explicit events instead of parsing the web request logs for referrers. At that time we saw a large enough % of missing events from send beacon (caniuse still reports no sendbeacon for IE or safari) that we decided to collect via referrers.

@EBernhardson See my earlier comment. The existing methodology is not a problem from a technical perspective. The method used is fine. But it does not require it to be visible in the address bar while viewing the search page, nor after the user goes back to the SERP.

It should be solvable by delaying the change to the address bar until a link is clicked. (Verify that browsers includes changes from onclick in its referral).

I will see about getting access to browserstack so i can try out the late-URL edit and see how it works across browsers.

Pulled a test set of browsers reporting to search eventlogging for sept 1-12 in P7539. This is not the same data as is collected in the code for this ticket, but is a close enough representative sample that is very easy to query. That data additionally isn't perfect since there is a target sampling rate (x events per wiki per day) rather than some percentage of all requests, but it's probably close enough. It will essentially down-weight some of the largest wikis in the stats. Below is everything with >1% of distinct search sessions for sept 1-14, as classified by our eventlogging user agent classifier.

This is missing mobile, because the satisfaction schema doesn't run on mobile. The click tracking here does so i pulled a second set of top browsers from https://pivot.wikimedia.org

Overall everything except IE 11 works, and the proposed change did not cause that. The pre-existing use of history.replaceState triggers that bug.

Change 460110 had a related patch set uploaded (by EBernhardson; owner: EBernhardson):
[mediawiki/extensions/CirrusSearch@master] Only add searchToken to url when something is clicked

https://gerrit.wikimedia.org/r/460110

Change 460110 merged by jenkins-bot:
[mediawiki/extensions/CirrusSearch@master] Only add searchToken to url when something is clicked

https://gerrit.wikimedia.org/r/460110

OK, that makes sense. I was going to suggest adding the extra parameters to the beginning rather than the end of URL, so the search query is still at the end, but it looks like I can just add ns0=1 to my initial search query to avoid the redirect, which works well enough. Thanks for clarifying!