Related (somewhat) to T271387: [M] Handle case of erroneous search filter values in URL.

Re-checked the query + - = && || > < ! ( ) { } [ ] ^ " ~ * ? : \ / with https://commons.wikimedia.org/w/index.php?title=Special:MediaSearch&cirrusDumpResult=&q=https://commons.wikimedia.org/w/index.php?title=Special:MediaSearch&cirrusDumpResult=&q=%2B+-+%3D+%26%26+%7C%7C+%3E+%3C+%21+%28+%29+%7B+%7D+%5B+%5D+%5E+%22+~+%2A+%3F+%3A+%5C+%2F&ns0=1&ns0=1

and got
[YD1pbx3mOtrK6ao1jkOFzwAAAAs] 2021-03-01 22:23:43: Fatal exception of type "ApiUsageException"

@Etonkovidova Can you help me understand how this ticket differs from https://phabricator.wikimedia.org/T271387?

T271387 is when filters have an invalid value that we don't know how to handle in the UI (it's not one of the values that could be chosen in one of the dropdowns). It can only be achieved by manually mishandling the URI (or via software that messes up links) since we provide no controls to construct a search like that.
This is actual search input (can simply be entered in the search input field) that the search engine just happens to fail to process and make sense of. It's a rather extreme edge case, but it's plausible that it happens by accidental user input.
(FWIW, I think we can give both the same generic error msg treatment)

Thanks @matthiasmullie, that makes sense.

Yeah, following the same sort of message works for me. Maybe this one keeps the search chrome though.

There is now a patch up for T271387, so once that is merged we can probably tackle this quickly and apply the same behavior. I'll update the acceptance criteria in this ticket to make it clear that this concerns errors due to invalid search terms as opposed to invalid filter settings.

In T273839#6880624, @mwilliams wrote:

Thanks @matthiasmullie, that makes sense.

Yeah, following the same sort of message works for me. Maybe this one keeps the search chrome though.

I think that when a "bad input" search is initiated from the JS UI, this is what we'd want to show the user (because the rest of the search chrome was already there when the user submitted the bad query).

If the bad input is present on the PHP side (perhaps because the user copied/pasted a link that included bad query parameters), we may want to handle things in the same way we do for T271387 where the rest of the chrome is never added to the page; we'd probably want bail early as soon as we detect that something is wrong (this is how we're handling invalid filter settings).

I agree that the same message and icon from the invalid filter can be re-used here (in both scenarios).

Change 668758 had a related patch set uploaded (by Eric Gardner; owner: Eric Gardner):
[mediawiki/extensions/WikibaseMediaInfo@master] Handle invalid search strings

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

Here's a side-by-side example of the PHP and JS versions of this error message:

PHP version (user copies/pastes a bad link, has bad params in their URL, etc):

JS version (user enters bad input after page JS initializes)

In the latter case, clearing the bad search term also clears this message and returns to the empty state, so they can try again.

Both messages display an identical link that just reloads the page with no parameters if clicked.

Change 668758 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Handle invalid search strings

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

Tested in betalabs (also see this comment in T271387.

JS - bad user input	no-JS bad user input
- type filters are present; - "Enter a new search" is not a link	- tab filters are present; - "Enter a new search" is not a link (it shouldn't?)

@egardner - please review the following questions

• the screenshots from betalabs look different than in your comment
• should the error message (and UI) be different between the case when there is a bad user input in the search textbox and when a user pastes the url with invalid search criteria (and correct url parameters)?

For commons wmf.36 two specs are missing (per the screenshots in @egardner comment

• "Enter a new search" is not a link
• PHP version (no-JS) still includes the search text field

I'll do additional check on commons wmf.37.

Hi @Etonkovidova – in recent weeks we were able to improve the error handling so that both JS and non-JS users saw the same thing essentially – the complete search UI (input, tabs, etc) with the error message in the area below. There is no longer a need for a link to restart a new search, because the user can just do so immediately without navigating. I think it is safe to say that our acceptance criteria have changed slightly now.