Aloha ;)

Und wenn sich noch jemand mit mobilem Windows, dem Apfelzeug oder anderer skurrilen Geräten finden würde, der nach einer Anmeldung mit Benutzer: "adm" und dem Passwort "GeHeim" das Frontend der Benutzerverwaltung testet (und die eventuellen Fehler/Unzulänglichkeiten meldet) - dann wäre ich geradezu glücklich.

Skurrile Geräte? Challenge Accepted. Soeben liegt der Nintendo 3DS meiner Frau neben mir. Dann schauen wir doch mal.

Testprotokoll:

Testlinks auf der Login-Seite: Tun was sie sollen.

Eingeloggt.

Die Testlinks funktionieren auch hier wie gewollt.

Administrationswerkzeuge:

Alert: Es ist ein Fehler aufgetreten: [object XMLHttpRequestProgressEvent]

Alert: Es ist ein Fehler aufgetreten: {"users":["adm","bar", ...} [object XMLHttpRequestProgressEvent]

Anlegen eines neuen Benutzers schlägt fehl (wird nicht angelegt).

Anlegen einer neuen Gruppe - beim Klick auf "Speichern":

Browserfehler: 012-1032 - Diese Datei kann nicht geladen werden.

Die Gruppe wurde dennoch angelegt.

Löschen einer Gruppe: Beim Bestätigungsfenster löst ein Klick auf "Ja" keine Aktion aus, der Klick auf "Nein" verfrachtet einen wieder auf die Überblick-Seite.

Vorweg: Natürlich ist eine Unterstützung durch den 3DS nicht unbedingt zu erwarten ;) Trotzdem ist die Analyse testweise interessant, weil sie evtl. besondere Schwachstellen aufdeckt, die bei normalen Konfigurationen nicht auftauchen.

Der Nintendo 3DS benutzt einen von Nintendo selbstgebastelten Browser.

Das Problem mit XMLHttpRequest... würde ich direkt dem unzulänglichen Nintendo-Browser zuschieben; da besteht kein Anpassungsbedarf.

Interessant für mich ist, dass das Benutzer anlegen nicht funktioniert hat (nicht unbedingt verwunderlich, wenns XHR-Probleme gibt), das Gruppe anlegen aber wohl schon (Ich habe das nochmal getestet, es funktioniert tatsächlich.

Auch die Meldung, die mir da erscheint, ist etwas schleierhaft - das ist die Fehlermeldung, wenn irgendeine Datei heruntergeladen werden soll, die das System nicht akzeptiert. Das einzige was da nach dem Klick auf den Button aber kommen sollte, ist HTML. Etwas merkwürdig, vielleicht hat sich an dieser Stelle noch ein Bug versteckt?

Weiter im Text. Gibt es einen Grund, warum der Ja-Button nicht funktioniert, der Nein-Button aber schon? Werden die intern anders angesteuert? Auch hier vielleicht nochmal drüberschauen.

Alles in allem ist das natürlich jammern auf hohem Niveau, im Browser funktioniert ja (fast, siehe unten) alles; auch auf dem kleinen Display des Nintendo ist die Bedienbarkeit super.

Während ich das geschrieben habe, sind mir noch zwei weitere Dinge aufgefallen (diesmal im Google Chrome / Windows 7):

1.: Ich habe mal Testweise mein Browserfenster klein gezogen. Das flackert beim Ziehen ganz ungut. Das ist nicht weiter tragisch (wer zieht schon die ganze Zeit sein Fenster groß und klein), aber doch nicht normal - deshalb die Erwähnung.

2.: Es gibt in den devtools ein Warnung: "Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check http://xhr.spec.whatwg.org/."

3.: Der "Daten neu laden"-Button hat zwischendurch nicht funktioniert und bei jeder Betätigung Fehlermeldungen in den devtools geworfen. Da ich leider zwischendurch ausgeloggt wurde ist die Fehlermeldung verloren. Die Meldung war irgendwas mit dem unerwarteten Zeichen "<" in (index):1, aber frag mich nicht, wie genau die Formulierung war. Jedenfalls ist die Sache nicht ohne weiteres reproduzierbar, selbst wenn ich gleichzeitig weitere Benutzergruppen mit dem DS erstelle...

So weit so gut von mir, ich stehe für weitere Tests gerne zur Verfügung ;)

Grüße,

RIDER