Change 511020 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/core@master] Revert "Make powersearch form use POST if JS is disabled"

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

My impression is that while reverting this patch may fix the problem for now, the larger problem is that advanced search has decided to take over the URL and redirect users around. Having this kind of code split between multiple code bases (core and advanced search) seems like an anti-pattern. If the functionality of ensuring the URL always contains the namespaces is useful then it should be implemented in core. This would ensure extensions don't go around breaking core in subtle ways as it changes.

Change 511025 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/AdvancedSearch@master] Enforce a GET request when the "remember" user setting doesn't change

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

How to reproduce

• You need to be logged in.
• Click the magnifying glass in the top right to go to Special:Search. This is critical. If you are already on Special:Search and try to reproduce the issue, it will most probably work as expected all the time.
• Change the namespace selection from the default you got to something else.
• Type something like "test" and hit enter.
• Result: The namespace selection is reset back to the previous default (whatever that was for you).

Repeating this multiple times without leaving the page will most probably not trigger the bug.

Possible fixes

• I confirmed locally that https://gerrit.wikimedia.org/r/508933 is indeed the cause, and reverting it would make the issue go away.
• The Advanced-Search code currently doesn't fiddle with the method="…". It's expected to be fine, but after https://gerrit.wikimedia.org/r/508933 it is not. It's always POST for logged in users, which is not correct in all situations where the "Remember selection" checkbox is not checked. Only if it is checked, the form should use POST. https://gerrit.wikimedia.org/r/511025 picks this idea up and forces the form to use GET when the "remember" checkbox is not checked. Otherwise it will accept the method as provided by the backend.

@EBernhardson, I had a look at the AdvancedSearch\Hooks::redirectToNamespacedRequest() function you pointed at, but it is not involved in this issue.

Change 511020 abandoned by Thiemo Kreuz (WMDE):
Revert "Make powersearch form use POST if JS is disabled"

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

@thiemowmde This indeed appears to be the same problem my bug described, but this sums it up much more succinctly, and has more useful details.

Incidentally, I'm not able to reproduce it on the English Wikipedia in the manner described in your previous comment; for that matter, I'm not able to reproduce it on the German Wikipedia either.

Change 513089 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/AdvancedSearch@master] Fix failing hook handler test with an anonymous user

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

I think we should force-merge the bugfix even if tests are failing (as long as the fix itself can be demonstrated via tests?), and split the remaining test fixes into future work.

In T223709#5193519, @E_to_the_Pi_times_i wrote:

@thiemowmde This indeed appears to be the same problem my bug described, but this sums it up much more succinctly, and has more useful details.

Incidentally, I'm not able to reproduce it on the English Wikipedia in the manner described in your previous comment; for that matter, I'm not able to reproduce it on the German Wikipedia either.

I was able to reproduce it on German Wikipedia, but not with the steps above. Here are the steps I had to take:

• Log in
• Click the magnifying glass to enter the advanced search page
• Click the "search in" field
• Select an additional namespace, e.g. "File" / "Datei".
• Click the blue "Search" button.
• Note that at this point, the bug has *not* been triggered and the namespaces are correctly customized.
• Now, add or remove a namespace.
• Click "Search"
• Your namespaces will be reset to "Main".

Change 511025 merged by Thiemo Kreuz (WMDE):
[mediawiki/extensions/AdvancedSearch@master] Enforce a GET request when the "remember" user setting doesn't change

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

Change 514278 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/AdvancedSearch@master] Fix selectAll() helper unselecting selected namespaces

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

Change 514278 merged by jenkins-bot:
[mediawiki/extensions/AdvancedSearch@master] Fix selectAll() helper unselecting selected namespaces

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

Change 513089 merged by jenkins-bot:
[mediawiki/extensions/AdvancedSearch@master] Simplify HooksTest setup with real User objects instead of mocks

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

This task turned out to be pretty painful because of a multitude of unrelated failing tests. Here is a quick post mortem:

• A fix for the actual bug was found on May 18, but blocked for more than 2 weeks because of all the unrelated failures. We decided to force-merge https://gerrit.wikimedia.org/r/511025 on June 4.
• The HooksTest started failing, reporting a URL to contain an unexpected &ns120=1. 120 is the Item namespace from Wikibase. We suspect one or more Wikibase tests to leave the $wgNamespacesToBeSearchedDefault setting in a dirty state, but we never found this test. Maybe something in the WikibaseCirrusSearch codebase? Maybe @Smalyshev has an idea? We fixed it by removing an assumption from the AdvancedSearch test, see https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AdvancedSearch/+/513089/4, later squashed into https://gerrit.wikimedia.org/r/511025.
• The browser test automatically selects "All" preset when selecting all namespaces from the list of all namespaces started failing for the same reason. Fixed via https://gerrit.wikimedia.org/r/514278.
• It seems something in OOUI changed. Before, a browser test was opening the file type selection drop-down by clicking it's little down-arrow on the right side. This started failing. Instead, the test clicks the entire selector now. See https://gerrit.wikimedia.org/r/514260.
• One test does a login and logout. Based on what we have seen in the video we believe the logout was not finished, making the next assertion fail. We added a delay for now, also via https://gerrit.wikimedia.org/r/514260.

We decided the AdvancedSearch browser tests should run at least once a day. We are also thinking about making it a gated extension, but may postpone this decision until the browser tests are better parallelized.

We suspect one or more Wikibase tests to leave the $wgNamespacesToBeSearchedDefault setting in a dirty state, but we never found this test. Maybe something in the WikibaseCirrusSearch codebase?

I didn't see any tests in WBCS that manipulate $wgNamespacesToBeSearchedDefault.

Random breadcrumbs: The Translate extension includes a function wfAddNamespace which will set $wgNamespacesToBeSearchedDefault to true for the passed namespace ID. I don't see any usages, however.

Is it possible that a test runs this example file?

Wikibase/repo/config/Wikibase.example.php:    $wgNamespacesToBeSearchedDefault[WB_NS_ITEM] = true;

or this one...

Wikibase/repo/ExampleSettings.php:require __DIR__ . '/config/Wikibase.example.php';

Most likely is, Wikibase/Wikibase.php

if ( !array_key_exists( 'wgEnableWikibaseRepo', $GLOBALS ) || $GLOBALS['wgEnableWikibaseRepo'] ) {
    require_once __DIR__ . '/repo/Wikibase.php';

    if ( isset( $wgWikimediaJenkinsCI ) && $wgWikimediaJenkinsCI == true ) {
        // Use example config for testing
        require_once __DIR__ . '/repo/config/Wikibase.example.php';
    }
}

Maybe important: The URL gets truncated to https://en.wikipedia.org/w/index.php once you select "Remember selection for future searches" which is accessible when you expand/open "Search in:". Actually not for the current search, but for all following. And this field is accessible only when you are logged in. See T224796

Hi @Wurgl, the changes have not yet been deployed to the live version yet, they will be visible starting Thursday evening on de-wiki. However, they can already be checked on beta. Do you still experience the issues there?

Okay @Lea_WMDE, I thought/hoped it was deployed already on last Thursday. I tried on Beta and cannot reproduce any problems. So eagerly waiting for Thursday … If you like you can close it, I will not reopen any more.

Change 518007 had a related patch set uploaded (by WMDE-Fisch; owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/AdvancedSearch@wmf/1.34.0-wmf.8] Enforce a GET request when the "remember" user setting doesn't change

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

There has been some real-life discussion which I'll relay here: last week's train (1.34.0-wmf.10) was rolled back due to unrelated breakage, so this fix is not live yet. Next week's train (Wednesday, wmf.11) will include the fix. There's some ongoing negotiation about possibly pushing the fix out on Monday ahead of the train.

Change 518007 merged by jenkins-bot:
[mediawiki/extensions/AdvancedSearch@wmf/1.34.0-wmf.8] Enforce a GET request when the "remember" user setting doesn't change

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

Change 518756 had a related patch set uploaded (by WMDE-Fisch; owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/AdvancedSearch@wmf/1.34.0-wmf.8] Enforce a GET request when the "remember" user setting doesn't change

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

Change 518756 merged by jenkins-bot:
[mediawiki/extensions/AdvancedSearch@wmf/1.34.0-wmf.8] Enforce a GET request when the "remember" user setting doesn't change

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

It works as expected in deWP. thanks

@Wurgl Thanks again for the help!