Welp, that is mightly silly. As a wild guess, Safari is ignoring our styles for the field because it is <input type=search />? This looks like a worse variant of T106096 (which is this, but in Chrome).

Can you see if removing 'type' => 'search', from SpecialSearch::shortDialog() fixes it? If yes, we should do that.

Resetting the built in CSS with: -webkit-appearance: textfield; or -webkit-appearance: none; seems to work.

Looking at this bug together with T106096, I think we should just disallow type: 'search' config for TextInputWidget, and make a SearchTextInputWidget (SearchInputWidget?) with the fancier custom UI with "clear" button/indicator and type=search + -webkit-appearance: textfield; for semantic goodness.

Eh, actually, that would be somewhat inconvenient.

Not really related to this task but is anything supposed to happen when you click on the icon? When I hover over it, the cursor changes to a pointer giving the expectation that something's supposed to happen when I click on it. However, nothing happens. This seems like broken behavior to me.

Thanks for filing this task. This is happening in Safari 7 as well. (I noticed this issue when debugging a separate search input + layout bug in Safari, but I didn't have time to investigate fully.)

Change 226069 had a related patch set uploaded (by Bartosz Dziewoński):
TextInputWidget: Handle type: 'search' better

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

In T106348#1466781, @Glaisher wrote:

Not really related to this task but is anything supposed to happen when you click on the icon? When I hover over it, the cursor changes to a pointer giving the expectation that something's supposed to happen when I click on it. However, nothing happens. This seems like broken behavior to me.

That was T98213 and was just recently fixed. The icon indeed does nothing, it's just an icon.

Change 226069 merged by jenkins-bot:
TextInputWidget: Handle type: 'search' better

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