Fontfehler wenn der Chrome (Windows) Passwortmanager ein Form ausfüllt?

[Rolf B]

Hallo alle,

ich habe ein Login-Form gemacht und für einfacheres Testen stehen die Test-Credentials im Chrome für Windows Passwortmanager.

Wenn ich die Seite mit dem Form lade, füllt Chrome Userid und Passwort sofort aus. Aber: Er wendet nicht den Font an, der im CSS angegeben ist. Erst, wenn ich auf die Seite klicke (sprich: die erste Interaktion durchführe), wird der Font angewendet.

Ich dachte zuerst, das läge daran, dass ich einen Webfont verwendet habe, aber nein, es passiert auch bei Systemfonts. Auf der Testseite, die als problematische Seite verlinkt ist, habe ich font: 2rem cursive; eingestellt, da passiert es auch.

Test: Seite aufrufen, beliebige User-ID und Passwort eingeben, Anmelden drücken. Seite wird gepostet und fontmain.html kommt. Der Chrome Passwortmanager sollte fragen, ob er sich das merken soll.

Jetzt die fonttest.html Seite nochmal aufrufen. Lediglich den Zurück-Button drücken reicht nicht, dann wird der Passwortmanager nicht abgefragt. Zurück+F5 geht. Die Felder werden wieder ausgefüllt, aber nicht mit dem 2rem cursive-Font, sondern mit dem Default-Font der Seite. Das Benutzerfeld ist auto-fokussiert. Es genügt das Drücken einer Pfeiltaste oder ein Klick irgendwo in die Seite, damit die input-Felder gestyled werden.

Ich finde dazu keinen Chromium-Bug. Bevor ich einen öffne - mache ich was falsch?

Abgesehen davon, dass ich den Google Passwortmanager verwende und Passwort-Autofill an ist. Aber das ist eine Testseite in der Entwicklung…

Unter Chrome/Android fällt es nicht auf, da werden die Eingabefelder (bei mir) nicht autogefüllt. Keine Ahnung, ob ich das da einschalten kann.

Und nein, Gunnar, diese HTML Seite ist keine Vorlage zum Erstellen anderer Seiten und keine bedienbare, zugängliche Produktivseite. Es ist eine minimalistische Repro-Seite für ein Fontproblem. Du kannst Dir also deinen pet peeve sparen.

Rolf

[Gunnar Bittersmann]

@@Rolf B

Wenn ich die Seite mit dem Form lade, füllt Chrome Userid und Passwort sofort aus. Aber: Er wendet nicht den Font an, der im CSS angegeben ist. Erst, wenn ich auf die Seite klicke (sprich: die erste Interaktion durchführe), wird der Font angewendet.

Fürs Bugticket, wenn du eins schreibst: Auf macOS dasselbe Fehlverhalten.

(„Verwende einen anständigen Computer!“ zieht also nicht. Nur „Verwende einen anständigen Browser!“ 😉)

Mein Brave (ebenfalls Chromium) füllt die Felder nicht gleich aus, sondern bietet das Ausfüllen an. Da ist sie aber, die Interaktion, die die Schrift richtig macht.

---

Und nein, Gunnar, diese HTML Seite ist keine Vorlage zum Erstellen anderer Seiten und keine bedienbare, zugängliche Produktivseite. Es ist eine minimalistische Repro-Seite für ein Fontproblem. Du kannst Dir also deinen pet peeve sparen.

?? Das Formular ist zugänglich; die Labels stehen über den Eingabefeldern. Was sollte es da noch zu meckern geben?

🖖 Live long and prosper

[Raketenwilli]

Zwei „K“ („Kaffee“, „Kippe“) sind erledigt, warten auf das Dritte.

Wenn ich die Seite mit dem Form lade, füllt Chrome Userid und Passwort sofort aus. Aber: Er wendet nicht den Font an, der im CSS angegeben ist. Erst, wenn ich auf die Seite klicke (sprich: die erste Interaktion durchführe), wird der Font angewendet.

Fürs Bugticket, wenn du eins schreibst: Auf macOS dasselbe Fehlverhalten.

Ja, ich konnte das nachvollziehen.

Version 151.0.7922.71 (Offizieller Build) built on Debian GNU/Linux 13 (trixie) (x86_64)

wenn ich sodann auf den Eintrag (egal ob Benutzername oder Passwort) klicke, wird die von Dir vorgesehene Schrift verwendet:

ich habe dann mal andere Eingaben verwendet und ebenfalls gespeichert. Ach siehe da …

… Sobald man einen Eintrag aus der kaum lesbaren Box auswählt wird das Formular wie vorgesehen dargestellt. (Siehe 2. Bildschirmfoto)

Also die „falsche“ (browserintern vorgesehene) Schrift erscheint immer dann, wenn die vom Browser selbst generierte Select-Box offen ist und die Einträge noch gar nicht wirklich mit der Webseite, sondern in einem Overlay gerendert werden. Nach der Auswahl eines Eintrags sieht alles so aus, wie von Dir gewünscht - erst dann stehen die Daten aus Sicht des Browsers auch in der Webseite.

Jetzt aber fix. Das dritte „K“ will erledigt werden.

[Rolf B]

Hallo Raketenwilli,

Das dritte „K“ will erledigt werden

Klo? Küche? Krillen? Kaltes Bier? Kicken?

Danke für die Rückmeldung!

Rolf

[Tabellenkalk]

Hallo,

Hallo Raketenwilli,

Das dritte „K“ will erledigt werden

Krähen killen? Katze küssen? Klüsen koordinieren? Karren kitten, krasse Kometen kommentieren? Korpus kaschieren, Kommode komplettieren, kurz Kurze kürzen...

Gruß
Kalk

[Rolf B]

Hallo,

ich habe gerade bei Google nochmal nach "chromium bugs passwortmanager autofill font" gesucht.

Sie verlinken diesen Thread als Quelle!!1!elf!!! - ich fühle mich beklaut 😡

Aber: Danach geht es weiter mit:

#How to Fix or Bypass

CSS Override: Use a high-specificity CSS rule or box-shadow trick in your stylesheet to target the internal autofill state:

input:-webkit-autofill,
input:-webkit-autofill:hover, 
input:-webkit-autofill:focus {
  font-family: inherit !important;
  font-size: inherit !important;
  transition: background-color 5000s ease-in-out 0s;
}

was sie bei medium.com gefunden haben. Und das ist doch mal was. Gleich ausprobiert!!! Und funzt nicht.

Und es gibt wohl sogar einen Grund: Das Security Issue 40093523! Ich habe es nicht genau verstanden, aber offenbar meint man, dass sich durch das Setzen eines Default-Fonts verhindern lässt, dass bestimmte Exploits möglich sind.

Rolf