Page MenuHomePhabricator

[M] Handle users who arrive on the page with the obsolete "bitmap" parameter
Closed, ResolvedPublic

Description

Earlier in the development of MediaSearch, the tab for image search results was named bitmap instead of image. It's also the default tab, so many old links (and indexed urls) may send users to the page with this older and no-longer-valid parameter.

Currently this triggers an error which shows up in the logs, and presents the user with the page in an invalid state (no tab selected, no error message or results visible, etc).

Acceptance Criteria
[] Users should see an error message if they land on the page with an invalid type parameter

  • Users who show up on the page with an invalid or missing type parameter should be silently redirected to the Image tab, and their URL should be altered to match.

Note: We discussed this and decided it's no longer necessary: For the special case of type=bitmap, let's automatically redirect the request to be type=image with all other parameters left unchanged.

Related: T277724

Event Timeline

CBogen renamed this task from Handle users who arrive on the page with the obsolete "bitmap" parameter to [M] Handle users who arrive on the page with the obsolete "bitmap" parameter.Apr 21 2021, 4:52 PM
CBogen updated the task description. (Show Details)

Change 682201 had a related patch set uploaded (by Eric Gardner; author: Eric Gardner):

[mediawiki/extensions/MediaSearch@master] Handle missing or invalid tab when JS UI initializes

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

I should note that the open patch here does not exactly align with the acceptance criteria. What happens instead is that users who arrive on the page with an invalid type parameter (?type=bitmap, ?type=foo, etc) will instantly and silently get redirected to (?type=image), the default search type. All other params remain and the UI then loads normally. The URL gets updated to include image as well, so users copying-and-pasting the resulting page will have valid links going forward.

If this behavior is not adequate, we may need to end up re-working how we do error handling here. Right now we are not doing server-side error handling at all.

I should note that the open patch here does not exactly align with the acceptance criteria. What happens instead is that users who arrive on the page with an invalid type parameter (?type=bitmap, ?type=foo, etc) will instantly and silently get redirected to (?type=image), the default search type. All other params remain and the UI then loads normally. The URL gets updated to include image as well, so users copying-and-pasting the resulting page will have valid links going forward.

If this behavior is not adequate, we may need to end up re-working how we do error handling here. Right now we are not doing server-side error handling at all.

This sounds good to me!

I've opened a separate task (T281173) to address the other gaps in our error-handling behavior. This fix can be applied in the meantime.

Change 682201 merged by jenkins-bot:

[mediawiki/extensions/MediaSearch@master] Error handling improvements in JS and PHP

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

Test cases checked in betalabs shows that the js error is present for the cases with invalid values for type and with search parameters. When type is missing entirely - it behaves as expected. I'll re-check in production after all related patches for handling errors will be merged.

For type=foo the testing results are the same as for type=bitmap.

@Etonkovidova this patch (like most patches going forward) was applied to the stand-alone MediaSearch extension version of this code – as opposed to the code that lives inside of WikibaseMediaInfo.

Right now the Special:MediaSearch page on Commons (and presumably on Beta) is still powered by the old codebase (which did not get this patch). Sometime in the next week or two, the new extension will go live and the mediasearch code that lives inside of WikibaseMediaInfo will be deleted.

Locally, I have the new extension activated and am able to test things locally at Special:NewMediaSearch. But I don't think the extension is enabled on Beta or Prod even if the code is deployed there.

Until the switchover happens this change (and most other patches currently in flight) may be difficult to test on Beta/Production.

Re-checked the test cases on commons wmf.9 - all seem to be good now. I've updated my comment above (https://phabricator.wikimedia.org/T280425#7064189) to indicate that all tests are successful now.