dupe? https://phabricator.wikimedia.org/T140390

This task needs more discussion/mock and estimation before working on it, but we'll keep it in Needs Analysis on the sprintboard as the next thing to work on.

This is a regression and easy to fix.

Change 299575 had a related patch set uploaded (by Jdlrobson):
Do not apply horizontal padding on basic search interface

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

@Jdlrobson wait.. what is the fix? just removing the magnifying glass?

For tiny resolutions up to 240px:

For 320px and higher:

Works! thanks jon

@Jdlrobson, @Nirzar: During testing, I noticed that the change removes the search icon in Opera Mobile at all resolutions, e.g. for an HTC Desire @ 480x800, an Amazon Kindle Fire @ 826x1234, etc. Is that the expected behaviour?

@phuedx thanks for catching that. according to @Jdlrobson's comment above it shouldn't "for 320px and higher"

Per @bmansurov's review of the change.

A check on http://en.m.wikipedia.beta.wmflabs.org/wiki/Main_Page?cb=foo1 from Opera Mini in Opera Mini mode (full page proxy server compression mode) on an iPhone 5c running iOS 9.3 suggests the issue persists.

@dr0ptp4kt: @Jdlrobson's change hasn't been merged yet…

Ah, okay, thanks! Looks like I was checking on something already in the -1 column! Should have checked Gerrit, too.

Patch still needs review though... https://gerrit.wikimedia.org/r/299575

Change 299575 merged by jenkins-bot:
Do not apply horizontal padding on basic search interface

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

Opera mini on Android, visiting http://en.m.wikipedia.beta.wmflabs.org/

Doesn't seem to be fixed.

From Joaquin on IRC:
main page, Opera mini on Android 6 opera mini 18.0.2254

I tested this myself. with Opera Mini 18.0.2254 the search actually works with JavaScript (it seems to be Webkit based and behave like Opera browser). On older versions of Opera I do not see the magnifying glass overlap.

Is it possible that you tested this before the fix to T141571 got deployed?
Could someone have another go at sign off? This looks good to me.

en.m.wikipedia.beta.wmflabs.org produces the same mashed together stuff as before. Just checked a few minutes ago. This was Opera Mini in Opera Mini mode (probably called "extreme" mode if you're checking from Android).

Ok yep I can now replicate this in opera mini with extreme mode (that said extreme mode does warn that some websites may not work correctly). That said this is an issue on production too. The user agent has changed for more recent opera minis and it wasn't clear from the bug report which opera mini we were fixing for...

Note I can't replicate this with user agent Opera/9.80 (Android; Opera Mini/18.0.2254/37.8773; U; en) Presto/2.12.423 Version/12.16. This particular problems seems to be a browser specific bug brought about when extreme mode is enabled.

Given this only impacts "extreme mode" which itself comes with a disclaimer ( extreme mode does warn that some websites may not work correctly) I question the high priority (seems more normal to me), especially when you compare to T141680 which impacts all browsers.

I'm not sure what exactly the numbers add up to in terms of how many people see this particular issue on every pageview, as compared to the other one, which affects RTL searchers who have entered the funnel. They both look strange, though.

Let's enqueue the other one ahead of this one, presumably both slated for sprint 79 so we can pull them in as time avails itself in sprint 78.

I'm still seeing the same mashed together stuff, checking from Opera Mini in "Opera Mini" (equivalent of extreme mode) on iOS. What are you seeing?

can we hide the magnifying glass for c grade? i was using android browser on gingerbread and the icon was mashed. i think we are investing a lot in fixing the icon

We can hide it for browsers where we don't run JS ((although that probably won't help Gingerbread. The icon is not generated the standard way - it is a background on an input which is probably causing a lot of these issues. I'd recommend using div.mw-ui-icon.mw-ui-icon-small. I would hope that would fix these issues.

@Jdlrobson - have we thought about how the new header will affect non-js browsers?

@ovasileva yeah for non JS browsers the magnifying glass takes you to a special search page. i guess this bug will get solved with new implementation because we are removing the header searchbar altogether

@Nirzar - whoo! (leaving this open as a double-check)

It looks fine to me... In that it is functional ... which is acceptable given it's grade C. What am i missing?

Note the negative text indent doesnt work on this browser

In T140490#3222938, @Jdlrobson wrote:

It looks fine to me... In that it is functional ... which is acceptable given it's grade C. What am i missing?

Note the negative text indent doesnt work on this browser

Last I checked text-indent works fine in Opera Mini (both positive and negative values). http://caniuse.com/#feat=css-text-indent and https://operamini.tips/#/css-text-indent confirm this. The new CSS4 each-line or hanging keywords are not supported in Opera Mini, but no other browser supports those yet either.

If I inspect the search icon in Chrome with JavaScript disabled, and disable the text-indent rule from mw-ui-icon, the label is still invisible (as it should be). And instead the label of the hamburger menu becomes visible:

This didn't happen on Opera Mini, which is further confirmation that text-indent works fine.

Rather, the rule that makes the label invisible most of the time is #searchIcon input { color: transparent; }. Re-enabling the text-indent rule and, disabling the color: transparent rule re-creates the same rendering we saw previously in Opera Mini.

The fact that this color: transparent was added is probably because someone realised that text-indent does not apply to native input buttons. So text-indent doesn't actually work here in other browsers either. (Not supposed to.)

I'm kind of wondering why this button is here in the first place. If you want accessibility, you could turn the icon itself into a <button>, use a child element for the label (which supports text-indent), or use an aria-label or title attribute. Or keep the current html, but ditch the hidden <input> button and apply a role attribute to the link that currently represents a button. There's these and lots of other solutions to choose from.

Thanks for the detailed write up. Yes this makes sense. I got a little confused as the HTML has changed considerably so mixing in with the history of this task confused me a little.

This is somewhat related to T163049 and will be fixed by https://gerrit.wikimedia.org/r/349261

You should probably raise a separate bug for the overlap on Special:Search - as the input there is rendered via OOjs UI not MobileFrontend's libraries.

Change 349261 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Search button should not be wrapped in a link

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

Change 349261 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Search button should not be wrapped in a link

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