Page MenuHomePhabricator

MediaSearch as default search not working on mobile
Closed, ResolvedPublic

Description

The MobileFrontend extension replaces the search form when a user clicks into it, and the replacement form doesn't have a title input to send the user to the right search page

Event Timeline

Change 676415 had a related patch set uploaded (by Cparle; author: Cparle):

[mediawiki/skins/MinervaNeue@master] Read default search page from the existing search, pass to MobileFrontend

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

Change 676420 had a related patch set uploaded (by Cparle; author: Cparle):

[mediawiki/extensions/MobileFrontend@master] Allow use of a search page that isn't Special:Search

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

  • Could you provide some replication steps to see this problem for myself not familiar with mediasearch?

*why isn't this a problem for desktop? Is there code in core that avoids this?

We've got quite a few hacks in the mobile search (in particular for Wikidata support) and are hoping to merge it with the desktop experience on the longer term, so I'd like to make sure however we do this, we are futureproofing it.

Change 676415 merged by jenkins-bot:

[mediawiki/skins/MinervaNeue@master] Read default search page from the existing search, pass to MobileFrontend

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

@Jdlrobson see here

https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/master/includes/MediaWiki.php#77

Most of the time the top-right search form has a "title" attribute, and it's normally set to Special:Search - see the code above, if "title" is set in the request that's the page the user ends up on (mostly). The value of "title" in the search form is what we overwrite in a WikibaseMediaInfo hook when we want Special:MediaSearch to be used as the default search page instead. In MobileFrontend there is no such attribute in the search form, and instead it relies on the behaviour on line 127 of the file above where the page defaults to Special:Search if the "search" request param is set. My patch to MobileFrontend just sets up the "title" attribute so our extension can modify it via a hook

Oh - also yes this works with the new desktop experience

Oh - also yes this works with the new desktop experience

Thanks for explaining!

I forgot that Wikimedia Commons doesn't use the new Vue based search experience (yet) but yes, I can see that we copy across the title in the same way. so this looks fine to me since when we switch the experience on mobile with the desktop one this should /just work/™. Thanks for your patience!

Change 676420 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Allow use of a search page that isn't Special:Search

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

Etonkovidova added subscribers: mwilliams, Etonkovidova.

@Cormac, @mwilliams - after checking in betalabs (and production commons wmf.4) I have some questions about desired behavior.

Presently (see the animated gifs below)

  • click in the Search field - an empty screen is presented (exactly as for Special:Search)
  • type some search item - cat, the results are displayed as though they would be for Special:Search
  • a user has to click on "Search within the pages" or to click on the mobile keyboard "Search" button to submit the search and be redirected to Special:MediaSearch
    media_search_default.gif (667×374 px, 211 KB)

Comparing with the desktop, the MediaSearch default on mobile looks more confusing.

Yeah, that's expected behaviour for now - https://phabricator.wikimedia.org/T279072 has been raised to modify the behaviour of the dropdown so that it's more like desktop

Yeah, that's expected behaviour for now - https://phabricator.wikimedia.org/T279072 has been raised to modify the behaviour of the dropdown so that it's more like desktop

Thanks! When T279072 is resolved, the search experience on mobile should be more consistent with desktop. I added some additional search test cases (for "Redirect to exact matches when searching" option too) to my list of test cases.

The patches for this task were backported; checked in commons wmf.4 amd closing this task as Resolved.