Reputation: 14244
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>
Update: This is a Chrome bug so remember to report it to the Chrome team (help -> report an issue).
Upvotes: 18
Views: 4030
Reputation: 131
This problem does not seem to affect <textarea>
inputs. To approximate a single-line <input>
element, you can use:
<textarea class="single-line-textarea" rows="1" wrap="off"></textarea>
<style>
.single-line-textarea {
overflow: hidden;
resize: none;
scrollbar-width: none;
}
/* For Safari, which doesn't yet support `scrollbar-width`: */
.single-line-textarea::-webkit-scrollbar {
display: none;
}
</style>
Note that textarea is not self-closing, so </textarea>
is required.
If you want the enter key to submit or move to the next field, hook oninput
and test if the entered characters include a newline:
document.querySelectorAll(".single-line-textarea").forEach((el) => {
el.addEventListener("keydown", (event) => {
if (event.key === "Enter") {
event.preventDefault();
}
})
el.addEventListener("input", (event) => {
if (event.data?.includes("\n")) {
// TODO: submit, move to next input, etc.
}
});
});
This is a longstanding issue with Android Chrome, so I'm not holding my breath for a fix anytime soon. From Google's support site:
Upvotes: 2
Reputation: 1598
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 *
Upvotes: 8