Firefox 3: CSS tables bug http://www.highresolution.info/weblog/entry/firefox_3_css_tables_bug/ 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. de-de Dirk Jesse Copyright 2009 2009-08-14T;06:44:10+00:00 Kommentar von Antonio http://www.highresolution.info/weblog/entry/firefox_3_css_tables_bug/ Dank an Dirk für Bugmeldung/Testcase und Hut ab vor den Entwicklern angesichts der superschnellen Reaktion! Dank an Dirk für Bugmeldung/Testcase und Hut ab vor den Entwicklern angesichts der superschnellen Reaktion!

]]> 2012-01-18T;11:39:34+00:00 Kommentar von Alexander http://www.highresolution.info/weblog/entry/firefox_3_css_tables_bug/ 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. 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.

]]> 2012-01-18T;11:39:34+00:00 Kommentar von Dirk Jesse http://www.highresolution.info/weblog/entry/firefox_3_css_tables_bug/ @Andreas Hab ich keinen “Montagsbrowser” erwischt? 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. @Andreas

Hab ich keinen “Montagsbrowser” erwischt?

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.

]]> 2012-01-18T;11:39:34+00:00 Kommentar von Andreas Hecht http://www.highresolution.info/weblog/entry/firefox_3_css_tables_bug/ 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? 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?

]]> 2012-01-18T;11:39:34+00:00 Kommentar von Ingo Chao http://www.highresolution.info/weblog/entry/firefox_3_css_tables_bug/ 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 ... 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 ...

]]> 2012-01-18T;11:39:34+00:00 Kommentar von Dirk Jesse http://www.highresolution.info/weblog/entry/firefox_3_css_tables_bug/ ... und im Falle der Implementation bei YAML kann ich table-row nicht definieren, denn das würde zusätzlichen Markup erfordern. ... und im Falle der Implementation bei YAML kann ich table-row nicht definieren, denn das würde zusätzlichen Markup erfordern.

]]> 2012-01-18T;11:39:34+00:00 Kommentar von Dirk Jesse http://www.highresolution.info/weblog/entry/firefox_3_css_tables_bug/ 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. 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.

]]> 2012-01-18T;11:39:34+00:00 Kommentar von Ingo Chao http://www.highresolution.info/weblog/entry/firefox_3_css_tables_bug/ 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. 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.

]]> 2012-01-18T;11:39:34+00:00 Kommentar von Ingo Chao http://www.highresolution.info/weblog/entry/firefox_3_css_tables_bug/ 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? 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?

]]> 2012-01-18T;11:39:34+00:00 Kommentar von Dirk Jesse http://www.highresolution.info/weblog/entry/firefox_3_css_tables_bug/ @Tobias Die genauen Umstände, was alles den Bug auslöst, sind nicht bekannt. Aber auch deine Info ist eine neue Erkenntnis. Gruß Dirk @Tobias

Die genauen Umstände, was alles den Bug auslöst, sind nicht bekannt. Aber auch deine Info ist eine neue Erkenntnis.

Gruß
Dirk

]]> 2012-01-18T;11:39:34+00:00 Kommentar von Tobias Bähr http://www.highresolution.info/weblog/entry/firefox_3_css_tables_bug/ 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. 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.

]]> 2012-01-18T;11:39:34+00:00