This is not actually a regression. The old header had the same issue.
The field is actually readonly for non-js users as the user doesn't interact with it - we pop open a search overlay when clicked.

Looking into the code the reason for this is explained in the comment:

		// don't use focus event (https://bugzilla.wikimedia.org/show_bug.cgi?id=47499)
		//
		// focus() (see SearchOverlay#show) opens virtual keyboard only if triggered
		// from user context event, so using it in route callback won't work
		// http://stackoverflow.com/questions/6837543/show-virtual-keyboard-on-mobile-phones-in-javascri

Seems like we have a couple of options

1. See if this is needed any more. We might be able to switch to use a focus event (rEMFR83ef66aa660c: Don't enable search enhancement on Android 2 suggests it was added for Android 2 which is now a grade C browser)
2. Add cursor: text; to the readonly field.

@phuedx any other ideas?

In T161763#3161017, @Jdlrobson wrote:

@phuedx any other ideas?

First, as you've said, double check whether any Grade A mobile UA's exhibit the same behavior as the Android 2 browser.

Add another element to the DOM immediately after the search box definition that looks like <input type="search" class="search" ... >, has tabindex="0" – is focusable with a keyboard, which readonly="" elements are but UA's will style them differently when they are focussed – and when tapped opens the search overlay, i.e.

<input class="search no-js-only" type="search" name="search" autocomplete="off" placeholder="Search Wikipedia" value="">
<div class="search js-only" tabindex="0">Search Wikipedia</div>

This coupled with your cursor: text; suggestion should work for all UA's regardless of any virtual keyboard idiosyncrasies.

@Jdlrobson @phuedx I assume the readonly is for js clients not no-js clients. If you apply readonly to no-js clients they can't enter any text.

In T161763#3164801, @Krinkle wrote:

@Jdlrobson @phuedx I assume the readonly is for js clients not no-js clients. If you apply readonly to no-js clients they can't enter any text.

Hah! Yes. See T161763#3161013. I've updated my comment accordingly.

This seems actionable to me... isn't the analysis part actually doing the task now @phuedx ? I'd suggest a timeboxed 2 pointer to avoid scope creep.

@Jdlrobson: Yes. I've moved to to Triaged but Future accordingly /cc @ovasileva

This task has been neglected for over a month now. We might want to consider it for an upcoming sprint.

(For the record, I just verified that current production still adds readonly with JavaScript after page load, and still causes the discoverability/accessibility issue.)

In short - <input> was not discoverable by:

• safari
• opera
• some IE versions
• Browser on android.

In some browsers "cursor:text" was applied only when the mouse pointer was over input placeholder.

I went with Sam idea and introduced a new element which is visible only for JS users. Tested on:

• IE10 @ Windows7
• IE11 @Windows 8, 10
• Edge @ Windows 10,
• Firefox (latest) @ Windows 7, OSX, Linux
• Opera (latest) @ Windows 7, OSX
• Chrome 59 @ Windows 7, OSX, Linux
• Browser @ Note 10.1/Android 5.1

Works properly now.

Change 368816 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[mediawiki/skins/MinervaNeue@master] Show cursor:text for JS-only users when hovering over search input

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

Change 368816 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[mediawiki/skins/MinervaNeue@master] Show cursor:text when pointing over search input

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

per @bmansurov suggestion, I changed the solution to add only cursor:text style and it looks like it solves the problem.

Change 368816 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Show cursor:text when pointing over search input

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

Any reason this skipped Needs QA?

This can skip QA as I believe it would be better verified by a developer who understands concretely what "grade A" browser means and requires some understanding of how browser accessibility works (how to use screen reader). I would like a developer to test and sign this off that's not @pmiazga

(posted draft - failed to hit submit)

@bmansurov @Jhernandez @Niedzielski: Which one of you can sign this off?

I was involved during review, I'd like to not sign off.

I'd appreciate if somebody would update the task with proper AC for signoff and maybe if you feel generous even QA steps.

The task is long and with a lot of comments and after reading it all I'm unsure of exactly how or what to sign off with how it is specified right now.

@ovasileva to add testing criteria

Apparently from discussion:

• This is a minerva desktop bug
• Cursor when hovering search input should be the text caret
• List of browsers to test on to be determined (See previous comment)

This is a minerva desktop bug

There is no mouse cursor on touch devices. This can be replicated on the mobile site or any old school browser that has or uses a cursor :)

It can be also done on touch devices with a pointing device like Samsung Note 10.1 (it has an S-Pen, if you keep S-Pen couple millimeters above the screen it will act as a mouse pointer).

So, this is what I wanted to read... It takes little time and makes a world of difference to people doing signoff or QA:

QA steps

• Load the URL on a window with tablet or desktop width (search input visible)
• Hover over the text input with the mouse
• Expected: Cursor changes to the text caret
  • Actual: Cursor stays with it's default form

Could reproduce on https://en.m.wikipedia.org/wiki/Dog with

• Chrome 59
• Safari 9.1.1

In don't see why we skipped QA on this one really, if we specify this ^ I think our QA would have been easily able to test it and more so in a bunch of browsers.