@Jack_who_built_the_house wrote:

Note that this happens even though keeping the button enabled is intentional per T141850#2662655.

that is about phabricator. a different website, codebase, interface and designer than the steps you wrote which are for English Wikipedia. (which runs on mediawiki not phabricator)

In T354107#9427991, @jeremyb-phone wrote:

that is about phabricator. a different website, codebase, interface and designer than the steps you wrote which are for English Wikipedia. (which runs on mediawiki not phabricator)

My bad, thanks!

Discussed with team and this doesn't seem like a UI issue on the special:search page, so unsure if we're able to help in any way. Moving this to tracking from the Web Backlog side.

In T354107#9454246, @ovasileva wrote:

Discussed with team and this doesn't seem like a UI issue on the special:search page, so unsure if we're able to help in any way. Moving this to tracking from the Web Backlog side.

What do you mean? I don't know how responsibility is divided in WMF, but this is definitely an issue of the scripts on Special:Search. It's not a browser issue – browsers don't behave that way by themselves.

This also happens in Firefox. After I press Enter the second time, this ends up in the DOM:

A very similar issue was reported yesterday on enwiki forums, but with pressing the "Back" button in the browser.

An IP editor investigated this here:

I think I understand what is causing this bug:

1. When clicking search it calls the setSearchSubmitTrigger function in modules/ext.advancedSearch.init.js;
2. $searchField is the actual searchbox element you type in, in line 60 that text is processed and saved to a variable, and in the next lines that value is put in a new, hidden, <input> element. This new element is created with a name attribute copied from the searchbox element (this hidden element is the one with name="search" in the image in that bug report);
3. In line 65 the value of the searchbox's name attribute ("search") is then cleared, the search then proceeds using the hidden element;
4. The bug then, is that when you navigate back on Chrome (and I guess Firefox), the page doesn't get (down)loaded again (browser cache?). The searchbox and this hidden element are still in the page and in this post-search state.
5. When you search again, it creates a new hidden element with a name attribute set to an empty string (because it's copying from the searchbox one and that one was cleared). When the search proceeds it then reuses the hidden element that has the name attribute set to "search", which is the one created in the original search.

If you stop the browser after this function is done (the bug report), these same conditions will be there when you try searching again.