14. August 2009
Es folgt mal wieder eine Bug-Beschreibung. Firefox hat aktuell ein ausgesprochen hässliches Problem in Verbindung mit CSS Tabellen und JavaScript. Die Kombination der beiden führt in einigen Fällen zu groben Renderingfehlern wobei einzelne Zellen einer Tabellenzeile scheinbar willkürlich in eine neue Zeile umgebrochen werden.
Das Rendering der CSS-Tabellen funktioniert prinzipiell, es ist also kein einfacher CSS-Bug. Ich verwende diese Technik in YAML zur Erstellung gleichhoher Container per CSS. Das eigentlich perverse an diesem Bug - er ist extrem schwer nachvollziehbar. Ich habe die CSS-Tabellen mittlerweile in mehreren Real-Live-Situationen ausprobiert und dabei bereits im Winter erstmals Bekanntschaft mit diesem Bug gemacht. Allerdings war die Fehldarstellung meist nach einem Reload oder auch nur dem Versuch eines Elementchecks mit Firebug verschwunden. Die Ursachenfindung hat das extrem erschwert. Erst vor einigen Wochen hat dann im YAML-Forum ein User einen weiteren Tipp beigesteuert, der letztlich einen Testcase ermöglichte.
Gestern Abend habe ich mich nochmals hingesetzt und endlich einen - zumindest bei mir - funktionierenden Testcase erstellt, sowie den Bug bei Bugzilla gemeldet (Bug 510350) . Die Einzelheiten zum Wie und Warum sind übrigens im Testcase ausführlich beschrieben.
Im Testcase wird der Bug durch eine fast leere Script-Node getriggert, wobei diese hier direkt im HTML-Code der Tabelle steht. Es ist die einzige halbwegs verlässliche Möglichkeit, den Bug zu erzwingen, die ich kenne. In meinen Real-Life-Layouts reichte meist schon die pure Anwesenheit von JavaScript in Form von jQuery oder sonstigem.
Und abschließend: Dieser Bug ist derart fies, dass sein Auftreten auf wundersame Weise sogar vom Dateinamen des Testcases beeinflusst wird. Auf meinem lokalen Rechner tritt der Bug - genau wie in der Netzversion - sporadisch auf. Wenn ich den Testcase jedoch in “index.html” umbenenne, wird er plötzlich permanent getriggert. Das verstehe wer will. Ich hoffe daher, die Mozilla-Jungs finden und eleminieren die Ursache möglichst schnell.
Freitag, 14.08.09 (12:02 Uhr)
Sehe ich das richtig, dass es egal ist ob JS aktiviert oder nicht ist? Weil bei mir wird es auch bei deaktivierten Zustand ausgelöst.
Freitag, 14.08.09 (12:12 Uhr)
@Tobias
Die genauen Umstände, was alles den Bug auslöst, sind nicht bekannt. Aber auch deine Info ist eine neue Erkenntnis.
Gruß
Dirk
Freitag, 14.08.09 (13:17 Uhr)
Das müsste Bugzilla #363326 sein.
https://bugzilla.mozilla.org/show_bug.cgi?id=363326
Du solltest immer auch eine table-row definieren.
Tritt der Fehler in Fx 3.5 auch noch auf?
Freitag, 14.08.09 (13:20 Uhr)
Wird keine Tabellenzeile definiert, kann es dazu kommen, dass eine notwendigerweise eingefügte anonyme Tabellenzeile bereits geschlossen und eine neue geöffnet wird, noch bevor alle Tabellenzellen ausgeliefert wurden.
Freitag, 14.08.09 (13:21 Uhr)
Hallo Ingo,
ja, der Bug ist auch in Firefox 3.5 weiterhin präsent. Deshalb wundert mit die Aussage bei Bugzilla #363326, dass er gefixt sei - den der Testcase gleicht meinem wirklich sehr.
Freitag, 14.08.09 (13:22 Uhr)
... und im Falle der Implementation bei YAML kann ich table-row nicht definieren, denn das würde zusätzlichen Markup erfordern.
Freitag, 14.08.09 (13:26 Uhr)
ja, eine CSS-Tabelle erfordert mindestens drei Ebenen: eine table, eine table-row und eine table-cell Ebene wegen dieses Bugs in Fx. Das mit dem zusätzlichen Markup ist so ne Sache: gewiss, aber laut spec werden diese ohnehin anonym eingefügt. Nur im Fx klappt das halt nicht. Hab mal irgendwann was dazu geschrieben ... nur wo ...
Freitag, 14.08.09 (14:22 Uhr)
Ich kann machen was ich will, ich kann anhand Deines Testcases den Bug mit FF 3.5.1 nicht nachvollziehen. Trotz sehr oft wiederholten Reload und egal ob Javascript aktiviert ist oder nicht.
Hab ich keinen “Montagsbrowser” erwischt?
Freitag, 14.08.09 (14:52 Uhr)
@Andreas
Nein, das ist das nervige. Er ist extrem schwer reproduzierbar, wie ich auch bezüglich der Erstellung eines Testcases geschrieben habe. Aber der Bug ist bei Mozilla bekannt und wird in FF 3.6 gefixt sein. Habs gerade mit der Alpha1 getestet.
Freitag, 14.08.09 (23:30 Uhr)
Das Problem wurde durch folgende Programmcodeänderung gefixt:
http://hg.mozilla.org/mozilla-central/diff/6b3cc966ef52/layout/base/nsCSSFrameConstructor.cpp
Ausschlaggebend ist der Befehl “RecreateFramesForContent” der nun in zwei bestimmten Situation aufgerufen wird.
Samstag, 15.08.09 (11:06 Uhr)
Dank an Dirk für Bugmeldung/Testcase und Hut ab vor den Entwicklern angesichts der superschnellen Reaktion!