wie Darstellung unvollständig geladener HTML-Seiten trigger?

Hallo,

wie kann man die Darstellung/Anzeige unvollständig geladener HTML-Seiten antriggern?

Ich hab einen HTTP-Server in einer kleinen Embedded-Schachtel und der sendet bei manchen HTML-Seiten den Inhalt sehr langsam zum Browser weil z.B. erst die angefragten Werte ermittelt werden müssen o.ä.
Firefox wartet mit der Anzeige jedoch bis die HTML-Seite vollständig übertragen (und die TCP-Connection beendet) wurde und das obwohl oft etliche Sekunden Pause in der Datenübertragung sind (manche Vorgänge können sogar Minuten dauern). Wenn so eine Pause kommt leert der HTTP-Server immer seinen TCP-Sende-Puffer und sendet im vorerst letzten TCP-Paket auch das Push-Flag mit (hab das mit Wireshark geprüft) so das ich davon ausgehe das Firefox auch alles an bisherigem HTML-Code empfangen hat aber dargestellt wird trotzdem nichts, das Fenster bleibt weiß und leer.

Gibt es irgendeine Möglichkeit Firefox zu vermitteln das er den bis dahin empfangenen HTML-Code schon mal darstellen soll?
Die HTML-Seite ist insgesamt nicht sonderlich groß, höchstens 20 kByte, könnte dies das Problem sein?

Ich erinnere mich das ich früher des öfteren eine wirklich sehr lange Seite (eine Tabelle mit mehreren tausend Zeilen) aufgerufen hatte, der HTML-Code war wimre mindestens 1 MByte, und Firefox noch während der Datenübertragung (die damals über 20 Sekunden dauerte) bereits angefangen hat die Seite darzustellen. Eingebettete Bilder (kleine Länderflaggen) wurden parallel geladen und auch dargestellt sobald verfügbar. Ich hab das damals extra mal mit Wireshark (hieß nur anders) mitverfolgt und man konnte wunderbar sehen wie parallel zu der langen TCP-Verbindung für den primären HTML-Code mehrere kleine TCP-Verbindungen aufgebaut und beendet wurden. Das vermisse ich beim heutigen Firefox.

Grüße
Erik

Hallo,

für alle die es interessiert, es liegt tatsächlich an der Menge der HTML-Daten. Wenn ich vor einer Pause noch einen längeren HTML-Kommentar <!-- .... --> übertrage (mindestens einige kB mit abschließendem Push-Flag natürlich) dann wird auch aller bisher übertragener HTML-Code dargestellt ansonsten wird die Darstellung offensichtlich erst durch das Schließen der TCP-Verbindung getriggert. Ich habe zu diesem Zweck extra einen speziellen HTTP-Test-Server gebaut der eine längere Tabelle (mit zehntausenden Zeilen) sendet und alle 1000 Zeilen für einige Sekunden pausiert. Wenn man in den Pausen nach ganz unten Scrollt sieht man wunderbar das die letzte Zeile nicht durch Tausend teilbar ist und demzuvollge noch irgendwelche Reste in internen Puffern im Firefox stecken müssen, Puffer im OS schließe ich wegen dem Push-Flag aus.
Im Chromium funktioniert die Darstellung übrigens perfekt, vor allem auch ohne extra Datenmüll um eventuelle Puffer zum überlaufen zu bringen. Das einzigste was mir beim Chromium aufgefallen ist ist das er bevorzugt vollständige HTML-Tags anzeigt. Wenn also zu einem <p> oder <tr> nicht auch das zugehörige </p> oder </tr> empfangen wurde wird das gesamte HTML-Tag nicht dargestellt, aber das ist okay für mich da ich ja weiß wo eventuelle Pausen kommen und dementsprechend den HTML-Code korrekt aufbauen kann.

Die Frage ist jetzt was ich da wegen Firefox tun kann. Firefox ist schließlich ein beliebter Browser (auch bei mir privat) so das ich ihn schon anständig unterstützen sollte. Aber was kann ich da nun machen?
Das Spielen mit den Einstellungen nglayout.initialpaint.delay , content.notify.interval , content.max.tokenizing.time , content.notify.ontimer , content.interrupt.parsing hat jedenfalls nichts gebracht. Gibt es noch andere Stellschrauben in Firefox an denen ich drehen könnte?
Wäre es vielleicht besser das als "Bug" den Entwicklern zu melden? Die eigentliche Intention der genannten Einstellungsmöglichkeiten ist, so weit ich das verstanden habe, schon dafür zu sorgen das die ankommenden Daten so zügig und so vollständig wie möglich dem User anzuzeigen und genau das funktioniert eben nicht. Andere Browser können das aber korrekt so das Firefox hier IMHO doch einen "Bug" hat.

Grüße
Erik

Hallo,

ich habe das mit Firefox 20, Firefox 31 und Firefox 34 nightly probiert, immer das selbe Problem.
Chromium 25 und Chromium 37 haben hingegen keinerlei Probleme mit langsamer bzw. stockender Übertragung.

Das gute alte "show as much as you can as soon as you can", siehe http://blog.codinghorror.com/the-lost-art-o…html-rendering/, scheint Firefox irgendwann mal verlernt zu haben.

Zum surfen im Internetz nutze ich einen anderen PC.

Grüße
Erik

Hallo,

Zitat von .Hermes

... mit einem neuen Profil nicht bestätigen.

Mit was für einem HTTP-Server testest Du das?
Macht der HTTP-Server auch wirklich mehrsekündige Pausen in der Datenübertragung (so das in dieser Zeit kein TCP-Paket übertragen wird)? Ist beim letzten TCP-Paket vor einer Pause das Push-Flag gesetzt?
Es kommt bei diesem Phänomen sehr auf das Verhalten des HTTP-Servers an.

Wenn nötig versuche ich mal einen geeigneten HTTP-Server ins Internet zu stellen.

Grüße
Erik

Hallo,

Zitat von .Hermes

Mit "Server: Apache/2.2.22 (Ubuntu)"

Theoretisch müsste man in einer per PHP o.ä. generierten Seite auch Delays und flush() einbauen können um das nachzustellen was mein HTTP-Server macht. Das Problem ist eben das manche Vorgänge zur Datenermittlung in der hiesigen Industrie-Anlage auch mal auf ein TimeOut o.ä. warten können und dann sieht man im Firefox so lange nichts und das ist doch sehr unangenehm.
Dass das Problem an meinem HTTP-Server liegt ist denke ich weitestgehenst ausgeschlossen da im Chromium alles ordentlich sofort dargestellt wird und auch Wireshark keinerlei Unstimmigkeiten aufgezeigt hat.

Zitat von .Hermes

Das macht Sinn.

Ich werd mir Mühe geben, wird aber vermutlich ein oder zwei Tage dauern. Ich brauche dazu einen Server mit Root-Zugriff und der Möglichkeit eigene Executables laufen zu lassen. Der HTTP-Server wird dann auch den TCP-Stack der Embedded-Schachtel bekommen so das der Test so realistisch wie möglich ist.

Hat den Firefox beim Datenempfang irgendwo einen Puffer (mindestens einige kBytes) der das von mir beobachtete Phänomen erklären würde?

Grüße
Erik