Flackern beim Seitenwechsel im MS IE

Viele Websites beinhalten Seiten, die vom Grundaufbau/Layout her völlig identisch aussehen. D.h., sie beinhalten viele begrenzende oder Hintergrunds-Elemente, die auf allen Seiten völlig gleich aussehen.

Bei einem Wechsel zwischen zwei Seiten erwartet man dann, dass die identisch aussehenden Seitenelemente während des Wechsel ohne jedes Flackern dargestellt werden. Der Wechsel soll für das Auge des Betrachters also so ablaufen, als ob nur die unterschiedlichen Seitenanteile im Wechsel neu aufgebaut werden. Die identisch aussehenden Elemente sollen beim Seitenwechsel dagegen als völlig statisch erscheinen. Es soll vor allem zu keinem Flackern beim Seitenaufbau kommen. Flackereffekte (kurzzeitige Hell-Dunkel-Wechsel in bestimmten Seitenbereichen) wirken auf die meisten Betrachter irritierend.

Leider stellt man aber immer wieder fest, dass es gerade bei komplexeren Seiten im MS IE zu diesem unangenehmen Flackern kommt – oft genau in den Bereichen, die beim Seitenwechsel eigentlich unverändert bleiben. Dagegen kann man bei Browsern wie Firefox, Opera, Konquerer oft  einen stabilen, flackerfreien Bildwechsel während des Renderns der neuen Seiten konstatieren. (Ausnahmen stellen Seiten dar, die Flash-Elemente beinhalten.) Wir haben das Problem schon des öfteren mit gewöhnlichen HTML-Seiten, aber auch im Zusammenhang mit PHP-Seiten festgestellt.

Wie kann man als Entwickler das nervige Flackern im MS IE in den Griff bekommen ?

Hierfür gibt es nach unserer Erfahrung mindestens zwei Tricks:

Trick 1: MS IE spezifisches Metatag

Im MS IE kann man den Seitenwechsel mit (teils spektakulären) Effekten unterlegen, die eine bestimmte Zeitdauer haben. Die Render-Engine arbeitet in diesem Modus anders als gewöhnlich. Wir nutzen das an dieser Stelle zur Vermeidung des Flackerns aus. Zur Parametrierung der Effekte dient ein Metatag der folgenden Form

<meta http-equiv=”Page-Enter” content=”revealtrans(duration=0.1,transition=5)” >

Der Parameter “duration” gibt die Zeitdauer des Effektes in Sekunden an, der Parameter “transition” den ausgewählten Effekt. In unserem Fall wird die Seite von oben nach unten aufgebaut (abgerollt) – die Zeitdauer ist allerdings so kurz gewählt, dass man das praktisch nicht merkt. Der von uns gewünschte Seiteneffekt ist allerdings der, dass ein Seitenwechsel nun in vielen Fällen völlig stabil und ohne jedes Flackern vor sich geht.

Weitere Information zu “revealtrans” findet man im Internet.

Trick 2: Einbau von Dummy-DIVs mit einer Opacity-Anweisung

Auch wenn man auf einem Layer der Webseite mit hohem z-Index ein Dummy-DIV mit einer Opacity-Vorgabe integriert, reagiert die Render-Engine des MS IE positiv im Sinne der Flackerfreiheit. Ein Element der Form :

<div style=”position:absolute; width:0.5em; height:0.5em; top:0.1em; left:0.1em; filter: alpha(opacity=66); -moz-opacity: .66; opacity: .66; z-index:10;”></div>

ist an sich zwar völlig sinnlos (da ohne Hintergrundsfarbe), zieht aber dennoch die Flackerfreiheit des Seitenaufbaus nach sich. (Ausschlaggebend für den MS IE ist dabei übrigens die “filter”-Anweisung.)

Viel Spass in Zukunft beim “Beruhigen” des MS IE.

Nachtrag am 18.11.2009: 

Im Falle von Hintergrundsbildern, die per CSS in Tags eingebunden werden, helfen die obigen Tricks in der Regel nichts. Siehe aber die Hinweise von Anne zu weiteren Möglichkeiten im Kommentar ! Danke, Anne !

Nachtrag am 28.11.2009

Anne hat mich darauf aufmerksam gemacht, dass beim MS IE in vielen Fällen auch der unauffällige Einbau eines kleinen Dummy-Flash-Films, der eigentlich nichts tut, zur Stabilisierung des Bildaufbaus und zur Vermeidung von Flackereffekten hilft. Wegen evtl. Schwierigkeiten mit Flash-Filmen in Gecko/Mozilla-Browsern ist das aber kein Trick, den man generalisieren könnte.

Interessant ist auch, dass im Moment das
gleichzeitige Öffnen mehrer Tabs mit Webseiten, die per SWFObjects 2.x eingebaute Flashfilme beinhalten, im Firefox zu Flackereffekten beim Seitenwechsel führt – zumindest unter Linux.  Es ist ein Leiden !

Ferner hat mich Anne mit einigen Beispielen, bei denen im BODY-Tag Hintergrundsbilder per CSS verankert wurden, davon überzeugt, dass es im MS IE (alle Versionen) manchmal sogar von Nachteil sein kann, den “revealtrans”-Effekt einzusetzen. Besser ist es da anscheinend, das Bild, das man im Body-Tag untergebracht hat, nochmal in Form eines gewöhnlichen IMG-Tags in einem DIV zu hinterlegen, das man per z-index unter allen anderen Seitenelementen einfügt.

OK, OK, ich gebe auf – es gibt keine Standardrezepte – man muss halt herumexperimentieren.

Wenn man Zeit hätte, könnte man ja die Sache mal systematisch untersuchen – Seitenwechsel bei vorhandenen Hintergrundsbildern, beim Vorhandensein  von Flash und das in allen gängigen Browsern unter Linux und  MS Windows.  Ach ja, man müßte dann auch noch die unterschiedlichen Arten der Einbindung von Flashfilmen berücksichtigen …..

samba – unix extensions bug?

Vor kurzem habe ich ca. 2 Stunden damit verbracht, mich mit einem vermutlichen Fehler in der Samba-Server-Version 3.2.7 unter Kernel 2.6.27 herumzuschlagen. (Die Kernelversion galt sowohl für den betroffenen Server wie auch die Linux-Clients).

Der Fehler bestand darin, dass “force create mode” und “force directory mode” Einstellungen des Samba-Servers ignoriert wurden, wenn User von unseren Linux-Clients aus Dateien/Verzeichnisse im Share anlegen wollten. Das hatte bei uns in der Praxis insofern Folgen, als die reibungslose Arbeit in der Gruppe u.a. von den Rechten der erzeugten Dateien abhing.

Die “force…”-Einstellungen waren gerade deshalb gesetzt worden, damit weder Windows- noch Linux-User der Samba-Shares über die Rechte-Einstellungen nachdenken mussten.

Das Problem im Detail und die Bedeutung der “unix extensions”

Ich habe für einen Share auf einem Samba-Server folgende Einstellungen vorgegeben:

[aux]

comment = aux
inherit acls = Yes
path = /samba/ann_aux
read only = No
create mask = 0664
force create mode = 0664
force user = myuser

Dieser Share wird in unserem Netz – wie gesagt – nicht nur von Win-XP Clients (natürlich in einer virtuellen Umgebung unter Linux) aus benutzt, sondern auch von Anwendern auf reinen Linux-Systemen. Dabei stellten wir dann fest, dass für einen berechtigten Linux-User zwar die “force user”-Vorgabe ausgeführt wurde, die Dateirechte jedoch immer auf “rw-,r–,r–“ gesetzt wurden, statt wie erwartet (“OR” – Kombination der Berechtigungs-Bits!) auf “rw-,rw-,r–“.

Der Rechtekamm “rw-,r–,r–“ entsprach nicht den “force create mode”-Einstellungen des Servers, sondern vielmehr den umask-Einstellungen für den betreffenden User auf dem Linux-Client.

Dagegen funktionierten die obigen Einstellungen auf einem deutlich älteren Samba-Server für ein anderes Share. Was also war der Unterschied zwischen den Servern? Nach einigem Suchen im Internet und Vergleichen kam ich dann dahinter, dass die Option “unix extensions” auf dem neueren Server gesetzt ist – defaultmäßig auf “yes”.

Dieser Parameter steuert für CIFS Shares die Anzeige und Nutzung von Linux-Rechten im Zusammenspiel zwischen Samba-Servern und Linux/Unix-Clients. Ich zitiere von “http://wiki.ubuntuusers.de/Samba_Server/smb.conf” :

CIFS Unix Extensionsunix extensions = yes

Dieser Parameter ermöglicht durch z.B. Samba Client/cifs auch auf dem Client die Original Dateirechte und Zeitstempel zu sehen und zu verwenden. Standardmäßig ist diese Option aktiviert; sie sollte nur bei Problemen mit diesen Extensions deaktiviert werden.
Die Einstellung kann nur für den gesamten Server geändert werden; unterschiedliche Einstellungen für einzelne Freigaben sind vom Server aus nicht möglich.

Dieser Parameter ermöglicht durch z.B. Samba Client/cifs auch auf dem Client die Original Dateirechte und Zeitstempel zu sehen und zu verwenden. Standardmäßig ist diese Option aktiviert; sie sollte nur bei Problemen mit diesen Extensions deaktiviert werden.
Die Einstellung kann nur für den gesamten Server geändert werden; unterschiedliche Einstellungen für einzelne Freigaben sind vom Server aus nicht möglich.

Weiter findet man unter “http://wiki.ubuntuusers.de/Samba_Client_cifs” folgende Ausführungen

Sind die CIFS-UNIX-Erweiterungen aktiv (auf dem Samba-Server: unix extensions = yes, Standard), so werden die echten Besitz- und
Zugriffsrechte zwischen Server und Client übertragen. Ändert man auf dem Client mittels chmod oder chown oder über den Eigenschaften-Dialog der GUI die Rechte, ist die Änderung ebenso auch auf dem Server und auf allen anderen Clients wirksam, die auf die Freigabe zugreifen.
Die Angaben in der Datei /etc/samba/smb.conf auf dem Server legen dabei den Rahmen fest, in dem Zugriffsrechte auf dem Client Gültigkeit haben. Ist z.B. eine Freigabe in smb.conf nur zum Lesen freigegeben, können für sie von keinem Client aus Schreibrechte festgelegt werden. Ist sie aber in smb.conf auch für Schreibzugriffe freigegeben, kann sie von jedem Client aus mittels chmod für “nur lesen” eingeschränkt werden. Ebenso können Freigaben, die auf dem Server den Status “nur lesen” haben, aber in smb.conf mit Schreibrechten eingetragen sind, vom Client aus mit Schreibrechten versehen werden.
Die UNIX-Erweiterungen haben Vorrang vor anderen Angaben für Besitz- und Zugriffsrechte. Sollten in der Mount-Befehlszeile oder im Eintrag in /etc/fstab solche Angaben vorhanden sein, so werden diese bei aktiven UNIX-Erweiterungen ignoriert.

Unter “http://us1.samba.org/samba/docs/man/manpages-3/smb.conf.5.html” liest man

unix extensions (G)
This boolean parameter controls whether Samba implements the CIFS UNIX extensions, as defined by HP. These extensions enable Samba to better serve UNIX CIFS clients by supporting features such as symbolic links, hard links, etc… These extensions require a similarly enabled client, and are of no current use to Windows clients.
Default: unix extensions = yes

Für Interessierte erwähne ich auch noch, dass auf dem Linux-Client beim Mounten eines CIFS-Shares auch ein Kernel-Parameter zur Nutzung der “unix extensions” gesetzt wird (bzw. gesetzt werden kann). Man werfe dazu nach dem Mounten des Samba-Shares einen Blick in das Verzeichnis “/proc/fs/cifs” und dort in die Datei “/proc/fs/cifs/LinuxExtensionsEnabled”. Ein

echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled

schaltet auf dem Client die Nutzung der vom Samba-Server angebotenen Unix-Extensions ab.

Soviel zur Theorie. Tatsächlich funktionieren die “Unix extensions” im Prinzip auch so wie vorgesehen – wenn man mal das “force create mode” außer Acht läßt :

  • Die User- und Gruppenrechte auf dem Samba-Server werden auf dem Linux-Client korrekt angezeigt. (Natürlich müssen auf dem Server und dem Client die gleichen UIDs und GIDs gesetzt sein wie auf dem Linux-Client!).
  • Jede Rechteänderung auf dem Linux-Client wird auf den Server übertragen.
  • Auch von MS Win-Clients aus funktioniert alles so wie vorgesehen – sogar das “force create mode” wird hier richtig ausgeführt.

Mein Problem besteht/bestand also darin, dass bei aktivierten “unix extensions” auf dem Samba-Server das gesetzte “force create mode” ignoriert wird, wenn man Dateien des Shares über einen Linux-Client anlegt. Das hätte ich schon aus Konsistenzgründen zu älteren Versionen des Samba-Servers nicht unbedingt so erwartet.

Die (vorrübergehende) Lösung

Probeweise habe ich den Samba-Server-Parameter “unix extensions” dann auf “no” gesetzt.

Danach wurden die Rechte von Files, die von Linux-Clients neu erzeugt wurden, tatsächlich wieder “korrekt” – d.h. gemäß der “force create mode”-Vorgaben – gesetzt. (Das Gleiche funktioniert natürlich auch, wenn man die entsprechenden Paramter für den Rechtemodus von Verzeichnissen benutzt.)

Blöd ist nur, dass die gewünschten und korrekt gesetzten User- und Gruppen-Rechte der Dateien auf dem Samba-Server nun natürlich nicht mehr auf den Linux-Clients angezeigt werden. Das war ja eigentlich der Sinn der “unix
extensions”. Aber damit kann man leben, wenn einem das Erzwingen von Rechten wirklich wichtig ist.

Eine Philosophie-Frage oder ein Bug ?

Nach diesen Erkenntnissen fragt man sich nun: Ist das eigentlich ein Bug ? Ich habe dazu zumindest einen Hinweis im Internet gefunden:

http://www.mail-archive.com/samba@lists.samba.org/msg99935.html und
http://www.mail-archive.com/samba@lists.samba.org/msg99936.html.

Natürlich könnte man aber auch wie folgt argumentieren: Wenn jemand die “unix extensions” benutzt, dann deshalb, weil man die Rechte auf dem Linux/Unix-Client selbst manipulieren will und soll. Irgendwie ist das ja der Kern der Sache. Also darf der User nicht voraussetzen, dass der Server die Rechtepolitik schon regeln wird. In meinem Fall hatte ich das auf Grund meiner Kenntnis des “force create mode”-Parameters explizit angenommen.

Andererseits:

Welche Chance hat ein Samba-Admin denn, wenn er trotz globalem “unix extensions” für bestimmte Shares auch für die User auf Linux-Clients vorgegebene Rechtekämme erzwingen will oder muss ? Lokal kann er ja für das betroffene Share die “unix extensions” nicht außer Kraft setzen – er muss auf dem Server also “force create mode” verwenden ! Aber das wird dann leider ignoriert !

Letztere Argumentation führt mich zu der Meinung, dass hier tatsächlich ein Bug vorliegt. Deshalb meine Aufforderung an die Samba- und Kernel-Profis: Bitte ändern – falls noch nicht geschehen !

 

Unison – Synchronisation mit GUI

Die gestrige Frage meiner geschätzten Gattin, wie ich es denn eigentlich so schnell schaffen würde, ein für unser Geschäft wichtiges Verzeichnis zwischen einem Linux-PC und einem Linux-Server, einem Windows XP-Laptop und einem anderen Linux-PC abzugleichen, ist vielleicht auch für andere Linux-User interessant.

Mein Freund und Konsolen-Liebhaber Michael würde nun antworten: “rsync”. Ich bin aber ein fauler Mensch. Und gerade im Konfliktfall muss man die Arbeitsweise und die Antworten von Rsync schon recht gut verstehen. Michael würde nun weiter sagen: Na, dann schreib dir halt ein Script. Meine Antwort darauf ist: Das haben andere schon gemacht – plus eine GUI dazu entwickelt.

Ein Beispiel für eine nette Applikation in diesem Umfeld stellt meiner Meinung nach “Unison” dar. Ich liste mal kurz die für mich wichtigen Eigenschaften auf:

  • Unison benutzt rsync, ist damit relativ schnell und vermittelt zwischen den Welten Linux, Unix, Mac OX und Windows.
  • Unison hat eine leicht zu überblickende und leicht zu bedienende graphische Oberfläche.
  • Unison erlaubt die Organisation der Abgleichvorgänge über Profile.
  • Unison gleicht Verzeichnisse natürlich auf Wunsch rekursiv ab.
  • Unison zeigt vor dem Abgleich an, was sich geändert hat.
  • Unison stellt Abgleichkonflikte in verständlicher Weise dar und gibt die Möglichkeit diese Konflikte pro Datei zu lösen.
  • Unison kann zusammen mit ssh benutzt werden.
  • Unison funktioniert auch über das Internet.
  • Unison funktioniert auch lokal – die abzugleichenden Verzeichnisse können auf ein und demselben Rechner liegen.

Letzteres ist besonders in Kombination mit NFS, Samba und smb4k interessant. Wenn keine größeren Sicherheitsanforderungen im lokalen Netz vorliegen und man die entsprechenden Rechte hat, hängt man die Laufwerke/Directories des Fremdrechners, auf dem sich das abzugleichende Verzeichnis befindet, einfach in das eigene Filesystem ein und führt dann den Abgleich durch. Das geht rasch und bequem.

Unison hat aber auch einen großen Nachteil – es funktioniert nicht, wenn der UTF8-Zeichensatz für Verzeichnis- oder Dateinamen ausgenutzt wird. Leider ! Wenn man aber im abzugleichenden Bereich diszipliniert mit konventionellen Dateinamen (ASCII 7) arbeitet, steht dem Einsatz von Unison als Synchronisationstool nichts im Wege – auch nicht für Arbeitsgruppen im Firmenumfeld.

Ein weiterer “Nachteil” ist ggf. der, dass man einen Abgleich zwischen mehreren Systemen durch sukzessive paarweise Abgleichvorgänge herbeiführen muss.

Dennoch: Einen Blick und einen Testlauf ist das einfach zu installierende Tool auf jeden Fall wert !