13

I have an HTML <input> element which, when focused in Chrome android, shows this annoying password management feature above the keyboard which takes up screen real estate. It's not a password type field so I'm not sure why this is happening. Any idea how to get rid of it?

<form id="guess-form" class="svelte-1o40qmd">
    <button id="btn-top" type="button" class="svelte-1o40qmd">▲ Top</button> 
    <input id="input-guess" 
      type="text" 
      spellcheck="true" autofocus="" 
      placeholder="Something" 
      autocomplete="off" 
      title="Something" 
      class="svelte-1o40qmd"/> 
    <input id="submit" type="submit" value="Guess" class="svelte-1o40qmd"/>
</form>

android keyboard1

Update: This is a Chrome bug so remember to report it to the Chrome team (help -> report an issue).

Benbob
  • 13,876
  • 18
  • 79
  • 114

1 Answers1

6

I came across this problem while creating a very similar thing. This is surely an Android Chrome bug as it makes no sense for a Password bar to be showing there.

The problem is evident on MDN when clicking into the sample input elements. It happens with type="text", type="number", type="password", type="tel", type="url", type="email"

But blessedly, it does not happen if you turn it into a search input, eg.

<input type="search" />

In my case, the input can actually be considered a search input of sorts, so I'm comfortable changing it to one as it makes semantic sense.

For anyone else who just wants to get rid of the unnecessary password bar, you will have to toss up whether throwing out semantics and accessibility is worth it.

And you will need to add some extra styling to try and make it look like a normal text input. In my testing, I only really noticed a difference in styling in iOS where a little search icon is added at the start of the input. To remove this, you can add the following CSS rule to the input

-webkit-appearance: none;

For completeness, you may also want to tackle the non-prefixed and moz-prefixed versions.

appearance: none;
-moz-appearance: none;

*Side note for OP: I also came across this problem while building a little game in Svelte, so my input looks almost identical to yours! You can see the game here with the input now changed to a search input *

Corrl
  • 6,206
  • 1
  • 10
  • 36
daamsie
  • 1,539
  • 10
  • 15
  • Thanks! So great to get some precious screen real estate back. By the way I like your game. I built a [redactle derivative game](https://redactle-unlimited.com/) using Svelte kit. – Benbob Sep 02 '22 at 02:57
  • 1
    Nice work. Damn that's tough! :) – daamsie Sep 02 '22 at 11:48
  • 2
    This is ridiculous... Even google.com has field type=text on desktop but changes the type to search for mobile agents. To be fair, it is THE search field, but why the incosistency? I've tested some other search engines and bing.com seems to be the only one so far that uses type="search" on both its variants. Is there more to this? – Yuri Sh Sep 03 '22 at 14:57
  • 1
    @daamsie - By the way you should also put these attrs on your input to prevent MS Edge popping up suggestions `aria-autocomplete="both" aria-haspopup="false"` - See https://stackoverflow.com/questions/73348295/prevent-input-suggestion-on-ms-edge – Benbob Sep 03 '22 at 21:05
  • @Benbob wow, Edge doesn't respect autocomplete="off" ? Good to know thanks. – daamsie Sep 04 '22 at 22:32
  • 2
    Is this a recent bug? If so, it's really disappointing to implement these workarounds when chrome can easily fix it by checking if input is type="password" – Caleb Taylor Oct 10 '22 at 04:22
  • In Chrome 110 the x of the search field is visible even with `appearance: none;` (so the wherdle input has two) – Corrl Feb 19 '23 at 17:06
  • @Corrl Hmm, I'm on Android Chrome 110 and can't see that behaviour. That seems an annoying new bug – daamsie Feb 22 '23 at 00:30