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
Description
Details
Related Objects
- Mentioned In
- T273979: [S] Add preference to allow users to keep Special:Search as the default target for the skin search input widget
T274927: [M] Add messaging to the MediaSearch page linking back to Special:Search and indicating that there is a preference - Mentioned Here
- T279072: MobileFrontend search bar dropdown suggestions link directly to pages
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
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
- 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?
- Does it work for the new desktop experience at https://commons.wikimedia.org/?useskinversion=2 ?
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
@Jdlrobson see here
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
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
@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
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
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.