After checking several versions, it seems like the last working branch for this issue was REL1_27. I was not able to locate the exact change that made the actual difference.

While related to search, someone from mobile frontend will likely need to take a look at this. Will leave it to them to triage the priority.

I am not sure this has to do with MFE, as the situation described is for using the non MFE interface.
Another interesting point - this issue is not appearing on Apple devices.

is the issue with Vector skin, Timeless skin, Minerva skin or all 3? From the description, it sounds like it's not anything to do with MobileFrontend...
Can you elaborate possibly with some screenshots, as I'm afraid I'm not understanding the bug you are reporting.

@Wess: I'm not aware of any autocomplete for text entered in the search box. Do you mean the dropdown proposals? Please clarify and also answer the questions by Jdlrobson.

@Aklapper - yes, the issue is with the search suggestions dropdown.
@Jdlrobson the issue is amongst several skins I've been trying, including Timeless and Vector. It's not a skin issue. It has nothing to do with MobileFrontend as it is relevant to the non MFE view. I will upload screenshots, but there's nothing in them (that's the issue...)
Here is the view from chrome browser on desktop while using mobile emulation in the inspector:

I can replicate in Timeless and Vector but not Minerva on a Samsung galaxy . More than likely a bug in jquery autocomplete which Minerva doesn't use

@Jdlrobson I am able to replicate the same issue on MW 1.31.3 with a custom skin that I have been developing from scratch without using MobileFrontend. This is clearly not a skin-specific issue.
To add onto what @Wess mentioned, the dropdown only worked when:

• Through a desktop browser.
• Through a desktop browser with mobile emulation
• Through the mobile browser when remote connected to a desktop using Chrome DevTools, but only works when interact through the desktop not the mobile.

It doesn't work when it is accessed through a mobile device.
I have tested with different browser on Android (including Chrome (Stable, Dev), Firefox (Preview, Focus), Brave), apparently it is not a browser specific issue as well.

To put more insight into this, the suggestion results does not update at all from its previous state when interacted through mobile (typing on the search bar).
All the suggestion results remained the same as the previous state, there is no change in both HTML and CSS when interacted.

EDIT: It is also reproducible on both En Wikipedia and MediaWiki in Vector, Timeless, Cologne Blue, Modern, and MonoBook.

I can also replicate this at will in Timeless, Vector, Example, and Poncho on Android Firefox, Firefox Preview, and Chrome, against both MW 1.33.1 and English Wikipedia. It also affects these mobile browsers when selecting "Desktop view". No desktop browsers appear to be affected (tested in Firefox 70+, Chrome, and Safari).

To add onto my comment before, the issue seems to be very widespread. Apart from the WMF wikis, I'm also able to replicate the same bug on RuneScape Wiki (without MF) and PCGamingWiki, in which both of them use a custom skin.

I am able to replicate the same issue on MW 1.31.3 with a custom skin that I have been developing from scratch without using MobileFrontend. This is clearly not a skin-specific issue.

But I'm guessing you are extending Skin without overriding the value of 'search' in getDefaultModules. Minerva does this and thus does not have the problem. The default skin shipped with MediaWiki is not designed with mobile in mind.

The problem is the search code in core is jquery autocomplete. This was not built with mobile in mind.

As part of the Desktop Improvements (Vector 2022) project we'll be likely looking to replace the search code in MediaWiki core with something more mobile-friendly, however this is not likely to happen any time soon. In mean time I suggest custom skins looking to work on mobile, provide their own JavaScript for search. The Minerva skin is the only skin I am aware of that replaces the search implementation and thus is the only skin not impacted by this issue so looking at its code will likely help with this.

@Jdlrobson It wasn't a problem in the older MW build like 1.27 so my best guess is that it could be related to the jQuery update to 3.X. Anyways thanks for the pointer, I'll share the result if I can find a solution that would help to migrate this issue.

EDIT: The search module is being replaced in MobileFrontend instead of MinervaNeue , there are too many dependencies to transplant the feature.

In T219590#5732996, @Jdlrobson wrote:

The Minerva skin is the only skin I am aware of that replaces the search implementation and thus is the only skin not impacted by this issue so looking at its code will likely help with this.

Given this affects every other skin, is there any particular reason the actually working js in Minerva isn't in core instead?

Given this affects every other skin, is there any particular reason the actually working js in Minerva isn't in core instead?

Minerva uses an overlay architecture and libraries that are not in core. At current time I would actually make a recommendation to use the search in the discovery portal (WMTypeAhead) - and would be keen to see that packaged up and in core and used by all skins, removing the jquery.autocomplete and Minerva code.

@Jdrewniak did an awesome audit of search - https://www.mediawiki.org/wiki/User:JDrewniak_(WMF)/notes/Search_widgets_at_Wikimedia and see T153417. We'll get to this as part of Desktop Improvements (Vector 2022) but I don't think there's a golden bullet for this. Experiments with Timeless using the discovery portal JS would be really useful to push us in the direction of a better library for all skins.

@Jdlrobson do you have a pointer on where can I look up the repo for the discovery portal?

@alistair3149 https://gerrit.wikimedia.org/g/wikimedia/portals/+/refs/heads/master it is.

Where is the source for this?

Oh, pfft. Thanks.

Also random note, this appears to only affect newer and up-to-date android devices.

Maybe.

For what it's worth, auto suggestions _do_ work on the same affected devices and sites from the search bar on Special:Search (OOUI; T100898).

@Oznogon The OOUI search uses a different search widget as I remembered, so it is not affected.
@Jdlrobson I ended up implementing WMTypeAhead with success but I don't know how or where to make a patch, I have given the code to @Isarra and see what he will do with it.

@Isarra is awesome I'm sure she'll be able to handle the patch part. Thanks @alistair3149! @Isarra happy to review if you did feel like moving this into core :)

Okay, having looked at what Alistair provided, we are not reusing even a subset of the portals js in timeless. That is some truly scary stuff.

Unless of course I cave and... oh gods why...

@Isarra we're about to experiment with a new Vue based implementation of search. Would you be interested in working with us on that (T244392) and seeing what it would take to integrate that into Timeless?

If it takes more than a simple include/activation + some styles to set it up, I'm gonna be honest, probably not. (Even the portals thing almost qualified as such, despite the js in questing needing to be copy-pasted into the skin directly, except it just didn't work out of the box with a lot of mw, either.)

Whatever the case, we really need to be heading for something that all skins can include/use with minimal work skin-side, and minimal overhead, that fully works. This means across browsers, on desktop and mobile, and preferably with various options if users want to hook it into pageimages/textextracts or whatever for extra info (depending on skin/target?). If the vue thing can do this, great, but Timeless would be the least of what we should be applying it to at that point (we're actually at the point where we may want to just drop in a replacement for core regardless, given the jquery autocomplete seems to not just be breaking on mobile, but even some desktop browsers these days...).

Whatever the case, we really need to be heading for something that all skins can include/use with minimal work skin-side, and minimal overhead, that fully works

That is my hope!

If it takes more than a simple include/activation + some styles to set it up, I'm gonna be honest, probably not

That was also my hope. If there were problems that stopped you doing that in Timeless I'd want to hear about them in the form of bugs.

I personally don't want to have to worry about/maintain a Vue as well as a jquery autocomplete implementation going forward. Right now the focus is on a Vector implementation but I think if we attack this from other skins perspective there's a chance we will land on something that works for all of us!

@Isarra the portal implementation could theoretically replace the current jQuery autocomplete in the core as a drop-in replacement. One of the major benefit of the new search suggestions (OOUI, Portal, etc.) is that it has rich suggestions with images and descriptions. With both PageImage and TextExtract as default extensions, it might be a decent starting point to replace the jQuery solution.

@Jdlrobson It seems to me that the Vue search might take a year or more to make it into core considering the amount of new tech requirements. Would it be worth a while to replace the core search suggestion module despite that Vue will replace it? And if so, I would love to help but I don't have enough knowledge to polish it to the standards, would there be anyone who are interested in helping out?

I experienced this bug too. Here are my findings for the Chameleon and the Vector skin:

On mobile (Android 8.0) suggestions are only shown after you entered a complete word (that's part of a page title) and a space.

Try to enter "geodistance " (with a space at the end) on https://maps.extension.wiki for example (on Android) and you get suggestions. If you enter "geo" only you don't see anything. I have this behavior on my Chameleon install as well.

Another find: If you enter weird letters like "@" there's an prompt reaction of the search box however.

Using Chameleon 3.0.1 and MediaWiki 1.34.1/1.34.2.
Also tested on Vector and MediaWiki 1.31.8.

I don't see any bug or feature request for jquery-client here. Please clarify and re-tag if I missed it.

I've investigated and the reason (on Firefox for mobile 81.1.4 at least) is that the keypressevent deosn't work on mobile.

The suggestions' update works when a keypress event is fired, however on mobile this event is often not fired at all, and moreover the key's code is set to 229 (dead key) when detected through a keydown event.

The suggestions update sucessfully for me when pressing a special character (like "("), where the key is correctly recognized. After pressing that character it works normally, the keypress event is always fired.

A solution could be to trigger the suggestion update with input event or keydown event while on mobile, but then we can't be sure that the pressed key inputs a character.

It's very late but if someone came to here as me and want to solve it without hacking the core, you can add simple js, in common.js or any other way

var $searchInput = $( '#searchInput,.mw-searchInput' );

		
		$searchInput.on('input',function(e){
			
			//trigger keydown with e object
			$(this).trigger(jQuery.Event('keydown', { 
				keyCode: e.keyCode,
				which: e.which, 
			}));
			$(this).trigger(jQuery.Event('keypress', { 
				keyCode: e.keyCode,
				which: e.which, 
			}));
		})

change $( '#searchInput,.mw-searchInput' ) to a relevant selector that includes all search inputs