Change 496011 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/skins/MinervaNeue@master] Remove Nokia60 override and use a CSS property order

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

Change 496059 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/skins/MinervaNeue@master] Add default focus treatment to search

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

There's a patch so let's talk about this!

Change 496011 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Remove Nokia60 override and use a CSS property order

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

Change 499928 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/extensions/MobileFrontend@master] Remove border nullification on header input

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

Change 496059 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/skins/MinervaNeue@master] Add default focus treatment to search

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

Change 499928 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Remove border nullification on header input

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

Change 496059 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Add default focus treatment to search

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

@ovasileva @alexhollender Patches are merged, pls decide if you want to QA that change…

@Volker_E awesome update.

The only two things I noticed to point out:

1. the focus state for the input field is styled differently than the other focus states. Would it make sense for them to all be consistent? I like the current styling of the input field, particularly on mobile.

2. This seems unrelated to the new patch from a technical perspective, but in terms of UX it's related. There is currently a focus state on some other input and textarea fields on Android, but they do not appear on iOS. Also noting that these focus states have a different styling than the new one we're introducing.

Android
iOS

When I'm testing this feature on https://en.m.wikipedia.beta.wmflabs.org/wiki/Main_Page I see a small blue outline flash. When I click search bar first it gets the blue outline, then (when overlay gets visible) it loses the blue outline and then after less than half of second it gets the blue outline again. In short -> it gets outline, loses the outline and gets the blue outline again. Then after it gets the outline second time it stays while I input search query.
The browser is Chrome 72 on Linux (Debian testing).

In T218154#5078211, @pmiazga wrote:

When I'm testing this feature on https://en.m.wikipedia.beta.wmflabs.org/wiki/Main_Page I see a small blue outline flash. When I click search bar first it gets the blue outline, then (when overlay gets visible) it loses the blue outline and then after less than half of second it gets the blue outline again. In short -> it gets outline, loses the outline and gets the blue outline again. Then after it gets the outline second time it stays while I input search query.
The browser is Chrome 72 on Linux (Debian testing).

I also see this on desktop. I'm not seeing this on mobile devices (iOS and Android), so hopefully it's limited to larger screens, but think it should be tested by others.

I can replicate:

The issue is the search overlay needs to focus the search input before it is shown (if that's even possible?)
Possibly the search focus should not be shown on the page where client-js is present (JS enabled?) Is that possible?

To expand on Jon's point, The reason that there's a flicker on the focus event is because when you click the search box in the header, what actually happens is that a new overlay is created that looks like the header (i.e. SearchOverlay) and the focus is shifted from the first search box to the second overlay search box.

The issue is the search overlay needs to focus the search input before it is shown (if that's even possible?)

My guess is that an element can't receive focus until it is visible, but I could be wrong.

The flash is pretty visible on my machine:

What about autofocus input attribute? https://www.w3schools.com/tags/att_input_autofocus.asp

What if we limited the :focus state styling to the actual search input? This is rough...I'm sure we could make it more seamless:

In T218154#5077346, @alexhollender wrote:

@Volker_E awesome update.

The only two things I noticed to point out:

1. the focus state for the input field is styled differently than the other focus states. Would it make sense for them to all be consistent? I like the current styling of the input field, particularly on mobile.

Yes, absolutely. Thanks for raising this. For anything that is an interaction element (buttons, dropdowns, radios, etc.) apart from pure links. It was just a lack of priorities/resourcing that held us back here.
Also here we're fixing a bug, in other cases we might just change behaviour (which from priorities is bad, from amount of work needed better.

2. This seems unrelated to the new patch from a technical perspective, but in terms of UX it's related. There is currently a focus state on some other input and textarea fields on Android, but they do not appear on iOS. Also noting that these focus states have a different styling than the new one we're introducing.

That's largely because with mediawiki.ui not loaded anz more and/or focus states not explicitly set across the board there are several occurrences that have no (bad) or different (not good) treatment. Such findings belong in a separate task though…

In T218154#5078960, @pmiazga wrote:

What about autofocus input attribute? https://www.w3schools.com/tags/att_input_autofocus.asp

autofocus won't help us here sufficiently and should, from UX perspective, also be chosen only very wisely…

In T218154#5079236, @alexhollender wrote:

What if we limited the :focus state styling to the actual search input? This is rough...I'm sure we could make it more seamless:

focus border issue.mov3 MBDownload

This is a great idea! I've actually shared this misbehavior as known on the patch. But your idea, in the way that the search overlay is built, makes total sense. Will propose a follow-up patch…
Was stuck too much in my unhappy confusion about having two inputs to do one thing.

Change 500877 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/skins/MinervaNeue@master] Provide focus styles only in overlay

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

Change 500877 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Provide focus styles only in overlay

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

So now when I tab through the UI the search doesn't get it's focus. Is that acceptable?

IMHO not acceptable. But the problem lies deeper, it's not about the visual focus. That's only minor aspect.
The overlay doesn't get triggered when input is focussed upon. User can't write the input.

Search input focus issue continued in T221194: Search input of overlay is not tab-able, inaccessible by alternative input users