Flash – Redraw/Reload-Verhalten von Browsern

So schöne Dinge man mit Flash machen kann: Beim Einsatz ist immer wieder Vorsicht geboten!

Wir haben z.T. sehr schlechte Erfahrungen mit dem Verhalten verschiedener Browser gemacht, wenn es darum geht, zwischen Seiten mit praktisch identischem Layout zu wechseln. Da in einem solchen Szenario viele Objekte im Browser gecached werden können, hofft man bei solchen Seiten auf einen sanften Übergang – also ohne viel Flackern beim Rendern der neuen Seite. Objekte die beim Seitenwechsel statisch bleiben, sollen auch im Browser statisch erscheinen.

Wichtig wird dies dann, wenn man auf einer Firmenseite viele einzelne Seiten hat, die im Hintergrund und in anderen Bereichen praktisch gleich aussehen. Hier möchte man als Betrachter einen ruhigen Wechsel ohne störende Reloads und ohne Neuzeichnen des Hintergrunds bzw. der statisch bleibenden Seitenelemente erleben. Nur veränderte Inhaltsbereiche sollen sich bei Rendern visuell sichtbar ändern.

Gerade dann, wenn die HTML-Seiten Flash-Objekte beinhalten, wird diese Erwartungshaltung an eine flackerfreies Browserverhalten aber oft genug nicht erfüllt. Im Gegenteil beeinträchtigt z.T. deutliches und wirklich störendes Flackern den Seitenaufbau. Zumal man hierfür als Betrachter keinen Grund erkennen kann und dies von Seiten ohne Flash-Inhalt auch nicht gewohnt ist.

Wir haben das “Redraw”-Verhalten von verschiedenen Browsern unter Linux und Windows ein wenig getestet. Hier unser Ergebnis, das wir auch an die Entwickler von Opera und Firefox weitergeleitet haben.

Unter Linux muss man feststellen, dass die von uns verwendeten Browser “Konqueror Firefox und Opera” generell den Bereich des Flashobjektes beim Wechsel zwischen nahezu gleichen Seiten neu zeichnen.

U.U. werden aber auch andere Objekte neu gerendert bzw. nachgeladen – gerade Firefox spielt hierbei eine unrühmliche Rolle! Dieser Browser zeichnet generell Layer (DIVs und ihren Inhalt) sowie Images neu, sobald die Seiten auch nur ein einziges (identisches) Flash-Objekt beinhaltet. Auch wenn sämtliche Elemente der Seiten gecached wurden. man muß allerdings festhalten: Das geschieht ausschließlich beim Wechsel zwischen Seiten, die Flashobjekte beinhalten. Hier kommt es – selbst bei 99% identischem Layout – zu deutlichen sichtbaren Beeinträchtigungen beim Bildaufbau. Interessanterweise zeigt die Windows-Version von Firefox dieses Verhalten nicht !

Dass es unter Linux auch viel besser geht, zeigen dagegen Konqueror und Opera. Beide Browser zeichnen nur den Flashbereich neu, wenn der Inhalt der Seiten zwischen denen gewechselt wird, praktisch identisch ist.

Überraschenderweise bietet Opera unter Windows das schlechteste Verhalten an. Hier wird alles neu gezeichnet, sogar der Hintergrund (bzw. die Hintergrundsfarbe) einer Seite. Resultat ist ein massives Flackern beim Seitenaufbau, da immer auch die Standardfarbe des Hintergrunds – nämlich Weiß – kurz sichtbar wird. Damit wird ein Wechsel zwischen Seiten mit einer Mischung aus HTML- und Flash-Content zu einem Erlebnis der besonderen, wenn auch negativen Art.

Das beste Verhalten bei unseren Tests zeigte der IE 7 unter MS Windows – allerdings auch nur, wenn die Seiten keinen komplizierten Layeraufbau mit vertikaler Schichtung aufwiesen. Mit vertikal geschichteten Layern kann der IE unserer Erfahrung nach beim Seitenwechsel insgesamt nur schlecht umgehen – im Gegensatz zu Firefox (solange kein Flash im Spiel ist).

Entfernt man die Flashinhalte aus Testseiten, so reduzieren sich die Flackereffekte, die mit dem Rendervorgang beim Seitenwechsel auftraten, sehr deutlich. Daraus ist zu schließen, dass das Zusammenspiel zwischen Flash-Plugin und der jeweiligen Browser-Engine in den betrachteten Browser-Varianten unterschiedlich gelöst wurde.

Deutliches Verbesserungspotential besteht unserer Meinung nach beim Firefox (Linux) und Opera (Windows).

Mehr und detailliertere Informationen sowie ein Testszenario findet man im Anhang (s.
nachfolgender Link).

Test zum Redraw Verhalten von Browsern beim Wechsel zwischen Seiten mit Flash-Content

Testdateien bitte per Mail vom Verfasse anfordern!

OX5 – Login Problem mit Konqueror – Nachtrag II

Es ist nun schon einige Zeit ins Land gegangen, seit das zuletzt beschriebene Login-Problem unter dem Browser Konqueror aufgetreten ist. Es gab auch einen erfreulich regen Austausch mit einem der KDE-Entwickler.

Leider haben die bisherigen Korrekturen zum korrekten Parsing von HTTP-Headern das Problem nicht behoben. Im Moment steht nur soviel fest:

1) Meine eigenen Tests in unserem Firmennetzwerk (mittels einiger PHP-Programme und einer Paketanalyse mit Wireshark) zur Interpretation von HTTP Redirect-Anforderungen (Refresh, Location – Direktiven) durch den Browser Konqueror sind alle positiv verlaufen. Daran scheint es also nicht zu liegen.
2) Die vom OX5-Server im Redirect angeforderten Cookies werden korrekt gesetzt. Der xhtml-Inhalt der HTTP – Refresh-Anforderung an den Browser wird korrekt dargestellt – der Refresh wird jedoch nicht mehr durchgeführt. Es wird kein entsprechendes HTTP GET – Paket an den Server zurückgesandt.
3) Das Problem tritt definitiv erst nach der ab Version 3.5.7-64.1 des kdebase3- bzw. des kdelibs3-Paketes auf. Nachweislich nicht nur auf meiner Installation. Es hat auch nichts mit der bei uns eingesetzten 64Bit Architektur zu tun.
4) Es ist unklar, wie Konqueror mit “chunked” Inhalt der HTTP-Pakete umgeht (“Transfer-Encoding: chunked”). Interessanterweise versendet der OX5 Server seine Mitteilungen an den Browser auf diese Weise. Mir drängt sich ein wenig der Verdacht auf, dass es evtl. ein Konqueror-Problem geben könnte, wenn die vorgegebenen “chunks” alle in einem einzigen IP-Paket Platz finden. Aber das müssen die KDE-Leute herausfinden.

Zusatzanmerkung:
Angesichts der seit 11. August geltenden Rechtslage (Strafrecht §202c) möchte ich betonen, dass eine gründliche Analyse des Problems eigentlich nur unter Beobachtung des Paketaustausches zwischen Client und Server möglich ist. Ich habe mir deshalb wegen der neuen Gesetzgebung als Inhaber der Firma selbst und höchst offiziell die Erlaubnis erteilt, in meiner zweiten Rolle als Administrator die Paketverfolgung in unserem firmeneigenen Netzwerk temporär und auf 2 Rechner begrenzt durchzuführen und danach alle eingesetzten Hilfsmittel wieder von den Systemen zu entfernen.

Wer das für schwachsinnig hält, hat zwar irgendwie Recht, möge sich aber bitte mal mit der neuen Rechtslage auseinandersetzen – danach stellt womöglich allein der Besitz von solchen Analyse-Tools ein Gesetzesvergehen dar (siehe etwa entsprechende Artikel in den letzten Ausgaben des Linux-Magazins oder aber aktuelle Artikel im PC Magazin) .

Diesem Wahnsinn haben übrigens alle Parteien außer der PDS im Bundestag zugestimmt. Wer also gegen die völlig diffuse Ausformulierung des §202c noch nicht beim Bundestagsabgeordneten seines Vertrauens protestiert hat, sollte dies nachholen. Hier ist insgesamt eine sehr ungute Entwicklung im Gang, die man als IT-Fachfrau oder -mann und als Demokrat nur mit allergrößtem Misstrauen beobachten kann. Hierzu schreibe ich aber bei Gelegenheit einen separaten Beitrag.