Page MenuHomePhabricator

[M] Handle case of erroneous search filter values in URL
Closed, ResolvedPublic

Description

The UI currently supports the following search filter options as URL params:

mimeType, imageSize, sort, and license.

If the user provides an invalid value for one or more of these parameters in their URL, the page should display an error message (with a link to start a new search); the normal search UI should not be shown.

Here's what it should look like:

02.jpg (656×1 px, 66 KB)

Event Timeline

Adding a screenshot to illustrate the issue in the task description:
e.g. invalid value in mimeType=jzz
https://commons.wikimedia.beta.wmflabs.org/wiki/Special:MediaSearch?type=bitmap&conceptchips=true&q=rose&mimeType=jzz
will result in the filter label not being displayed:

Screen Shot 2021-01-13 at 11.06.49 AM.png (556×1 px, 59 KB)

It's possible to "eliminate" all filters labels:

Screen Shot 2021-01-13 at 11.07.45 AM.png (491×898 px, 45 KB)

  • Is there a way for us to not remove/eliminate the filters with this error state? That makes this experience feel much more broken and like our mistake/bug rather than a user error.
  • In general our goal with error states in search is to: Clearly state there are no results and offer a path forward.
  • After chatting with @egardner he mentioned we will know specifically that this is broken due to an invalid value and not just a normal no results state. One easy way forward could be to replicate the current no results state with some updated copy to address all errors related to bad values for media type, filters, etc.

Screen Shot 2021-01-14 at 2.38.39 PM.png (546×1 px, 50 KB)
A bit wordy but relays exactly what is going on

Screen Shot 2021-01-14 at 2.42.52 PM.png (544×794 px, 39 KB)
Shorter and easier to read quickly and a bit more general.

  • Eric also brought up a good point about potentially generalizing all of our error messages into one like the example above or below since they are all starting to feel only slightly different. I think this could be a solution but would want us to keep an eye on it being too general to offer the right path forward (As we saw with the end of the results messaging).

Screen Shot 2021-01-14 at 3.00.44 PM.png (774×992 px, 72 KB)

In cases with invalid parameters, we might want to use language to convey that we didn't even attempt to find results because the original query was bad. Saying "no results were found" still implies we looked for them; something like "invalid search" might be more accurate here.

That makes sense. I don't think I'd usually use that phrase with most users but with anyone adjusting filters in their URL I imagine they will understand what is going on?

Screen Shot 2021-01-14 at 3.19.12 PM.png (516×776 px, 36 KB)

I think this is better – but maybe it would be best to just tell the user to "enter a new search above and try again" or something similar – then we don't need to imply what the cause of the problem was beyond the fact that something in their initial query was not valid (as opposed to a server error or something). I think "try again" should be the take away.

I re-checked how Special:RecentChanges handles incorrect url parameters - it seems it falls back to the default without giving any warning to users.
Special:Search informs users that e.g. "A warning has occurred while searching: Search profile of zadvanced is unrecognized, default search profile will be applied." But in many other cases of incorrect url parameters it falls back to default without informing users.

CBogen renamed this task from Handle case of erroneous search filter values in URL to [M] Handle case of erroneous search filter values in URL.Jan 19 2021, 5:22 PM
CBogen updated the task description. (Show Details)

Simple solution

02.jpg (656×1 px, 66 KB)
Message saying this is an invalid search with a link to media search

Potentially more complex but better solution

01.jpg (656×1 px, 84 KB)
Same message but inside of a blank/default media search ui

This experience is an edge case that we should try to spend as little time on. Happy to work with whoever picks this ticket up to finalize any other questions.

Just for the reference: there are three types of failed search requests

(1) failure of infrastructure (unavailable server or some other failure) - I didn't quite tested it.
(2) invalid search terms + - = && || > < ! ( ) { } [ ] ^ " ~ * ? : \ /
(3) invalid url parameters. The screenshots in the table below were made for the following urls:

Special:Search page gives different warning messages depending on the error. Below is the comparison of the current handling of (2) and (3) types errors.

TypeSpecial:SearchSpecial:MediaSearch
(2) invalid search termsThe warning is promptly displayed
Screen Shot 2021-01-20 at 12.18.23 PM.png (382×1 px, 66 KB)
The request never ends and there is no warning to users
Screen Shot 2021-01-20 at 12.18.11 PM.png (450×1 px, 58 KB)
(3) invalid url parameters e.g. ?type=123bitmap for Special:MediaSearch&profile=56343advanced
Screen Shot 2021-01-20 at 12.21.47 PM.png (447×1 px, 85 KB)
?type=123bitmap - the filters are missing
Screen Shot 2021-01-20 at 2.49.51 PM.png (527×934 px, 55 KB)
AnneT removed AnneT as the assignee of this task.Feb 3 2021, 9:06 PM

@mwilliams what do you think about showing this as the error message?

Screen Shot 2021-03-02 at 5.50.58 PM.png (1×2 px, 589 KB)

This is *slightly* different from your original mock-up because it still includes the proper page title and help link; the message sits in the content area. It might be helpful to keep those elements to provide some extra context for the user. Thoughts?

Change 667972 had a related patch set uploaded (by Eric Gardner; owner: Eric Gardner):
[mediawiki/extensions/WikibaseMediaInfo@master] Handle erroneous search filter params in URL

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

@egardner That seems reasonable to me, thanks!

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

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

Change 667972 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Handle erroneous search filter params in URL

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

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

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

Checked in betalabs - the URL parameters have been changed
mimeType -> filemime
imageSize -> fileres
license -> haslicense

Checked for invalid parameters:
filemime - https://commons.wikimedia.beta.wmflabs.org/wiki/Special:MediaSearch?type=image&q=rose&haslicense=other&filemime=tiff123&fileres=%3C500&sort=recency
fileres - https://commons.wikimedia.beta.wmflabs.org/wiki/Special:MediaSearch?type=image&q=rose&haslicense=other&filemime=tiff&fileres=%3C%3F00&sort=recency
haslicense - https://commons.wikimedia.beta.wmflabs.org/wiki/Special:MediaSearch?type=image&q=rose&haslicense=o123ther&filemime=tiff&fileres=%3C500&sort=recency
sort - https://commons.wikimedia.beta.wmflabs.org/wiki/Special:MediaSearch?type=image&q=rose&haslicense=o123ther&filemime=tiff&fileres=%3C500&sort=456

I varied the errors in the URL parameters but the resulting SpecialMediaSearch page always displays the search field and the filters. Since it differs from the screenshot in https://phabricator.wikimedia.org/T271387#6877266, a question to @egardner - given recent hiccups with betalabs, could it be specific to betalabs? Or testing is missing something?
I looked at https://phabricator.wikimedia.org/T273839#6887430 - so the screenshot without filters is only for no-JS case?

@Etonkovidova now that the train has gone out normally again, I think this can be re-tested on production commons (keeping the updated acceptance criteria for error handling from https://phabricator.wikimedia.org/T273839#6959224 in mind). Things seem to be working properly at first glance.

One thing worth mentioning is that unsupported parameters (as opposed to wrong values for supported parameters) are simply ignored, since there may be other parameters being used by mediawiki that we don't know about and don't want to mess with (debug=true for example). So entering filemime=foo should produce an error message, but if the users were to add the old mimeType parameter instead it would just be ignored regardless of its value. I'm not sure that we've formally specified this behavior but it is intentional here.

Etonkovidova closed this task as Resolved.EditedApr 2 2021, 9:48 PM

Checked in commons wmf.37
For &fileres=foo&filemime=foo&sort=foo&haslicense=foo the error message is displayed. The down-pointing arrows for filter menus are still displayed.

Screen Shot 2021-04-02 at 2.46.10 PM.png (557×910 px, 57 KB)

It definitely is an edge case.