Passwort-Manager in Safari will partout anmelden, trifft aber die Input-Felder nicht.

[dieselross]

Hallo Forum,

nach langer Zeit wieder einmal eine (vielleicht dumme) Frage von mir. Obige Seite enthält eine Passwortabfrage im Login. Aus Gründen der Rationalisierung liegt das Login in einem (tertiären) include, aus ästhetischen Gründen in einem Dropdown. Der Safari-Passwortmanager (auf dem iPhone) will nun partout anmelden (hinterlegtes PW vorausgesetzt) füllt aber beim Tipp auf "XXXXX verwenden" nicht das vorgegebene Passwortfeld aus. Folge: Die Passwortabfrage kommt bei jedem Seitenwechsel erneut. Nach erfolgreichem Login über das Loginfeld ist Ruhe, aber was, wenn der Besucher sich gar nicht anmelden will?

Ich bin am Verzweifeln.

[dieselross]

Oder weiter gefragt: welche Feldbezeichnung erwartet der PW-Manager für den Benutzernamen, denn das scheint der Knackpunkt zu sein.

[Rolf B]

Hallo dieselross,

das könnte ein Wurm im Apfel sein. Haben andere iPhone-Nutzer ähnliche Erfahrungen, angeblich seit Januar '24?

Aber…

ugh, ich hoffe, du bist nur Nutzer dieser Seite und nicht der Autor. Das ist ja sowas von 1999… Marquee mit grellrot auf grellgelb, Close-Buttons, die keine Buttons sind, sondern Bilder mit click-Handler, aua aua aua. Wenn man vom Suchbegriff aus mit Tab losläuft, kommt man auf Home, Kontakt, und dann scheinbar ins Nichts. Tabbt man weiter, sagt er auf einmal, dass das Passwort falsch sei. In einem Popup, aus dem ich per Tastatur nicht mehr rauskomme. Die Seite ist ein Bedienbarkeits-Fail. Dass Flaggen sich als Sprach-Icons nicht eignen, haben sie ja schon selbst gemerkt, bei der US/UK Chimäre. Das gehörte dann wohl auch für D/A/CH.

Und WAS bitte soll diese URL: https://rewakon.eu/shop/index.php?&width=1618&height=1011 - Fensterhöhe und -breite werden zum Server geschickt? Wie bitte?!

Rolf

[dieselross]

Danke für's (Nicht-) Eingehen auf die eigentliche Fragestellung. Stattdessen Bashing von Nebenaspekten auf die ich keinen Einfluss habe. Bin nur der Designer (das Marquee war genau so gewollt).

[Rolf B]

Hallo dieselross,

auf die eigentliche Fragestellung kann ich mangels iOS nicht näher eingehen, ich habe nur gegoogelt und festgestellt, dass andere über ähnliche Probleme berichten und daher die Vermutung mit dem Wurm (bzw. Bug) geäußert. Ich hoffe, dass auf diesen Hinweis hin die Selfkollegen, die ein iPhone haben (ich weiß von mind. 2), etwas dazu sagen können. Es gibt auch mehrere Seiten, die Vorschläge zur Lösung von falschen iPhone-Einstellungen machen, aber ich nehme mal an, dass Du die eh schon alle durch hast. Sowas wie Apple-Richtlinien, die eine Seite erfüllen muss, damit der Passwortmanager funktioniert, habe ich leider nicht gefunden.

Dass der Login-Dialog von einem Include eingebunden wird, sollte dem Browser egal sein, das Include findet serverseitig statt.

Aber eins sehe ich gerade: Der Login-Dialog steckt nicht in einem Formular. Bzw. er steckt im Hauptformular der Seite und nicht in einem eigenen Form. Und im Hauptformular steckt auch der Passwort-Ändern Dialog, mit input type="password" Feldern. Der Ändern-Dialog steht vor dem Login-Dialog, möglicherweise schreibt Safari das Passwort in das erste Passwortfeld zum Ändern des Passwords. Prüf das mal, schiebe - wenn möglich - mal den Ändern-Dialog ans Ende der Seite oder zumindest hinter den Login-Dialog.

Meine Kritik der Bedienbarkeit der Seite solltest Du nicht als Bashing ansehen, sondern als Meldung eines ernsten Problems.

Das Marquee ist Neben-Nebenaspekt und eh nur temporär. Click-Handler auf nicht-interaktiven Elementen und nicht funktionierende Tastaturbedienung sind hingegen kritische Fehler. Visuell wahrnehmende Maus- oder Touchbenutzer merken das nicht, alle übrigen werden von der Benutzung der Seite ausgeschlossen. Auf einer Privatseite könnte man behaupten, dass einem das egal ist (sollte man allerdings nicht). Auf einer Shop-Seite verliert man damit Kunden und Umsatz. Zugegeben, gute Bedienbarkeit ist nicht immer einfach und verlangt viele Tests.

Vorschläge:

• Verwende <button type="button">, um Buttons zu implementieren. Wenn Du sie mit CSS stylest, bekommst Du genau das Aussehen hin, das Du auch jetzt hast.
• Beschäftige Dich für Popup-Fenster mit dem <dialog>-Element. Die Evergreen-Browser können das seit 2 Jahren alle. Das Popover-API ist auch schick, aber noch zu frisch (Firefox erst seit April '24), finde ich.

Rolf

[dieselross]

Diese Kritik kann ich auch nachvollziehen. Tatsache ist: Ich bin nicht der Programmierer, dem arbeite ich lediglich zu. Die Bedenken bezüglich Bedienbarkeit teile ich zu hundert Prozent. Wenn du den (wie ich meine sauberen und gut strukturierten) HTML_Code, den ich anliefere sehen würdest, nachdem der Programmierer sein Werk daran verrichtet hat, würdest du Schreikrämpfe bekommen. Hunderte von Zeilen zu echo-Statements zusammengefasst. Fazit: kein Code-Folding mehr möglich. Editieren danach für Änderungen: Eins Strafe. Der Kunde und dessen Kunden arbeiten teils noch mit Rechnern unter WIN'95. Das muss ich alles berücksichtigen.

[Gunnar Bittersmann]

@@dieselross

Tatsache ist: Ich bin nicht der Programmierer, dem arbeite ich lediglich zu.

Das ist deine Ausrede?

Der Programmierer hat eine andere: Ich bin nicht der Designer, ich setze lediglich das um, was der Designer mir liefert.

Redet ihr auch mal miteinander? Das soll helfen.

Kwakoni Yiquan

[Rolf B]

Hallo dieselross,

Hunderte von Zeilen zu echo-Statements zusammengefasst. Fazit: kein Code-Folding mehr möglich.

Weiß er nichts von

   <?php
   // …PHP-Codewüste…
   ?>
   …html… <?= $value ?> …html…
   <?php foreach ($arr as $dings): ?>
      …HTML wiederholgruppe…
   <?php endforeach;
   // …mehr PHP…

Schade eigentlich. Das Umschalten zwischen PHP- und HTML-Mode kostet keine Laufzeit, verbessert aber massiv die Code-Lesbarkeit und vereinfacht die Schlacht um die Anführungszeichen.

Das ist das, was bei PHP so oft kritisiert wird: die Masse an Leuten, die sich Programmierer nennen, aber primär Copy+Paste gelernt haben und ihr Werkzeug nicht beherrschen. PHP ist in den letzten 20 Jahren deutlich besser geworden. Seine Nutzer auch?!

Versteh mich nicht miss: Ich habe schon begriffen, dass DU nicht dieser Programmierer bist.

Rolf

[Rolf B]

Hallo dieselross,

Der Kunde und dessen Kunden arbeiten teils noch mit Rechnern unter WIN'95.

Uh oh. Win95 brachte den hochmodernen Quirks-Master IE 5.5 mit 👀

Damit bist Du natürlich auf Uralt-HTML und -CSS festgenagelt. Welchen Browser-Mindeststandard setzt ihr denn für die Kunden voraus?

Obwohl - angeblich gibt's für Win95 ja noch den Opera 10 (von 2010, schon HTML 5 fähig) und angeblich auch Chrome 16.

Dass die Kunden mit den Museumsgeräten von den Hackern dieser Welt festgenagelt werden, steht zu befürchten, aber das ist ja nicht dein Problem. Es könnte natürlich sein, dass die heutigen Hacker-Kits auf diesem Uralt-Gerät auch nicht mehr funktionieren 🤣

Mein Hinweis mit der Dialogreihenfolge für die Passwort-Inputs gilt aber immer noch.

Rolf

[Der Martin]

Hallo,

Uh oh. Win95 brachte den hochmodernen Quirks-Master IE 5.5 mit 👀

oh no, so modern war Windows 95 noch nicht. Das hatte noch den IE3 an Bord (ab 95/2.0 gab's dann den 4er). Mit Windows 98 kam immerhin schon der IE4; der 5.5er war meines Wissens mit keiner Windows-Version "gebundelt", sondern nur als separates Installationspaket verfügbar.

Damit bist Du natürlich auf Uralt-HTML und -CSS festgenagelt.

Das auf jeden Fall. Tabellenlayout, darstellungsbezogene Attribute.

Einen schönen Tag noch
 Martin

[dieselross]

Danke sehr für den konstruktiven Hinweis auf das <dialog>-Element. Das hat in einigen Bereichen schon ‘mal sehr weitergeholfen. Die onklick-Handler dagegen kann ich dem Programmierer beim besten Willen nicht ausreden. Der ist noch sehr oldschool unterwegs.

[Gunnar Bittersmann]

@@dieselross

Danke für's (Nicht-) Eingehen auf die eigentliche Fragestellung.

Zitat #224

Stattdessen Bashing von Nebenaspekten auf die ich keinen Einfluss habe. Bin nur der Designer

Die Bedienbarkeit der Seite ist ein Nebenaspekt? Sagst du als Designer??

Kwakoni Yiquan

[dieselross]

Bitte nicht falsch verstehen. Selbstverständlich ist mir die Bedienbarkeit der Seite ein großes Anliegen. Leider habe ich auf die Gestaltung der Funktionselemente nur sehr bedingt Einfluss und das war eben auch nicht das Thema meiner Frage (insofern Nebenaspekt). Der Programmierer, dem ich diese ganze "onclick"-Misere verdanke, arbeitet schon wesentlich länger mit dem Kunden zusammen und der gibt vor, wie er das haben will.

Ein Beispiel, wie ich eine Seite aufbauen würde findet sich hier. Ja, auch hier war das Marquee so gewollt. Keine Ahnung, warum Kunden das immer noch haben wollen.

Wahrscheinlich noch immer verbesserungsfähig aber nur als Nachweis, dass ich es besser kann.

[Robert B.]

Moin,

Stattdessen Bashing von Nebenaspekten auf die ich keinen Einfluss habe. Bin nur der Designer (das Marquee war genau so gewollt).

konstruktive Kritik ist kein Bashing. So viel Fehlerkultur sollte schon sein, vor allem, wenn man Designer (oder Layouter?) für andere ist.

Viele Grüße
Robert

[Raketenwilli]

Hm. Ich bekomme mangels "Ich bin einverstanden" - Button nicht mal Zugriff auf die Seite.

• Firefox 126.0.1 (64-Bit)

[Rolf B]

Hallo Raketenwilli,

diesen Fuchs hab ich auch im Windows-Bau, aber ich sehe den "Button" (der ein p-Element mit click-Handler ist). Hast Du eine Filter-Extension drin, die solche p-Elemente als Sicherheitsrisiko einstuft und ausblendet?

Rolf

[Raketenwilli]

Hallo Raketenwilli,

diesen Fuchs hab ich auch im Windows-Bau, aber ich sehe den "Button" (der ein p-Element mit click-Handler ist). Hast Du eine Filter-Extension drin, die solche p-Elemente als Sicherheitsrisiko einstuft und ausblendet?

Rolf

Klar habe ich einen Add-Blocker. Die Fehlerkonsole meckert wie folgt:

• Das Cookie "warenkorbaenderungsid" verfügt über keinen gültigen Wert für das "SameSite"-Attribut. Bald werden Cookies ohne das "SameSite"-Attribut oder mit einem ungültigen Wert dafür als "Lax" behandelt. Dadurch wird das Cookie nicht länger an Kontexte gesendet, die zu einem Drittanbieter gehören. Falls Ihre Anwendung das Cookie in diesen Kontexten benötigt, fügen Sie bitte das Attribut "SameSite=None" zu ihm hinzu. Weitere Informationen zum "SameSite"-Attribut finden Sie unter https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite. shop

• unreachable code after return statement

Im Chromium geht es. Der grüne Button scheint auf.

[Rolf B]

Hallo Raketenwilli,

ok, die Cookie-Meldungen bekomme ich auch (für PHPSESSID und warenkorbaenderungsid). Der unreachable code ist in jquery.js, nicht im Autorenscript, und dürfte irrelevant sein, solange man Sizzle nicht außerhalb von jQuery verwenden will.

Im Firefox hab ich keinen Adblocker, den verwende ich "vanilla" um gelegentlich mal was unter FF zu testen. Da installiere ich jetzt auch nicht testweise einen 'rein…

Im Chrome läuft Avira, der mir bei in der Google Bildersuche nur die ersten Bilder durchlässt und den Rest wegschmeißt, aber den Button schmeißt er nicht weg.

Rolf