Beiträge von erik.v

Hallo,

was ich an Youtube bemängle ist das dem Firefox 31 auf der 64Bit-Version kein Support für die Media-Source-Extension zugetraut wird aber in der 32Bit-Version schon (auf dem 32Bit-System sind auch in der unteren Reihe 2 grüne Häkchen wogegen auf dem 64BitSystem nur oben grüne Häkchen sind, bei http://youtube.com/html5). Ich denke das ist ganz unabhängig von den Codecs, die auf meinen beiden Systemen identisch sind.

Wimre ist der WebM-Codec in Firefox fest eingebaut, ich kann mich jedenfalls nicht erinnern diesen extra installiert zu haben und unter Linux wird normalerweise nichts ohne die explizite Zustimmung des Users installiert.

Ich benutze Youtube recht häufig für die Hindergrundberieselung per Musik-Playlists und da ist es mir schon wichtig das alles zu meiner Zufriedenheit funktioniert. Da Youtube seit einiger Zeit einen Großteil des Contents auch per WebM-Codec anbietet verzichte ich seit einigen Monaten auf das Flash-PlugIn komplett (ist auf dem 32Bit-System in Firefox komplett deaktiviert und auf dem 64Bit-System erst gar nicht vorhanden, Adobe hat den Support für Linux eingestellt so das die Version 11.2.202 wohl die letzte bleiben wird, ich werde dem Flash-PlugIn sicher keine Träne nachweinen).

Mich würde wirklich interessieren was Youtube dazu bringt zu glauben das Firefox 31 in der 64Bit-Version keine Media-Source-Extension unterstützt aber in der 32Bit-Version doch. Könnte das eventuell wirklich mit der User-Agent-Kennung zu tun haben?

Grüße
Erik

Hallo,

Zitat von .Hermes

Du willst wirklich Kubuntu 10.04 und Kubuntu 14.04 vergleichen ?

Nein, ich halte es eher für sehr unwahrscheinlich dass das Problem mit dem OS zusammenhängt. Ich vermute mal stark das es um die Anzahl der Bits geht. Verwunderlich ist nur dass das alte System laut Youtube besser ist.

Da ich nicht wirklich ein Problem hab, läuft ja alles so wie ich will, dient dieser Thread eher meiner Neugierde. Ich würde wirklich gerne wissen was das modernere System mit dem deutlich aktuellerem OS für Youtube schlechter macht. Ich weiß das die Google-Services oft auf den User-Agent achten (ich hab das vor Jahren mal auf "Firefox" gesetzt und nichts ging mehr, überall kam die Meldung das mein Browser untauglich wäre) und vermute das es daran liegt, immerhin ist in dem User-Agent-String auch die Plattform-Architektur enthalten.

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

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,

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,

ich hab zwei PCs, einem mit 32Bit Kubuntu 10.04 und einem mit 64Bit Kubuntu 14.04, und auf beiden läuft Firefox in der selben Version 31.0 aber Youtube meint das beim Support der Media-Source-Extension die 32Bit-Version besser abschneidet als die 64Bit-Version. Bei http://youtube.com/html5 sehe ich beim 32Bit-Firefox 4 grüne Häkchen und beim 64Bit-Firefox nur 2 grüne Häkchen.
Beide Browser sind ziemlich identisch konfiguriert, haben exakt die selben AddOns installiert (welche auch exakt identisch konfiguriert sind), sogar in about:config habe ich erfolglos nach Unterschieden gesucht. Ich bin absolut ratlos warum Youtube den 64Bit-Firefox als weniger tauglich einstuft obwohl es doch exakt die selbe Version ist.

Kann es sein das Youtube den 64Bit-Firefox nicht als genauso tauglich erkennt wie den 32Bit-Firefox?
Das Adobe-Flush-PlugIn ist in beiden Browsern nicht vorhanden bzw. deaktiviert.
Noch andere Ideen was diesen Unterschied verursachen könnte?

Das Konsumieren von Videos klappt in beiden Browsern jedenfalls gleich gut, mal davon abgesehen das in dem 64Bit-System eine deutlich flottere neue CPU drin ist die für eine komplett ruckelfreie Darstellung sorgt wogegen die 12 Jahre alte 32Bit-CPU doch ziemlich an ihre Grenzen kommt.

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,

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,

ich hab das als Bug bei Mozilla reingestellt: Bug 909021.
Wer an der Behebung dieses Problems interessiert ist kann ja voten, damit dieses Thema auch mal endlich angegangen wird.

Ich hab noch ein bisschen mit anderen Browsern experimentiert und allem Anschein nach ist Chromium der einzigste Browser unter Linux der in der Lage ist per IPv6 ein SOCKS-Proxy zu benutzen (und das sogar per PAC-Script-Autoconfiguration also ohne manuellem Eingriff). Neben Firefox ist auch der aktuelle Opera für Linux (Version 12.16) nicht fähig ein SOCKS-Proxy per IPv6 zu benutzen, aber der kommt auch nocht nicht mal mit einer direkt eingegebenen IPv6-Adresse zurecht (er interpretiert die IPv6-Adresse als Domain-Namen und versucht damit eine DNS-Auflösung was natürlich schon aufgrund ungültiger Zeichen im Domain-Name vom DNS-Server abgelehnt wird) und Wireshark hat noch ganz andere Merkwürdigkeiten in der IP-Kommunikation des Opera offenbart.
Die Programmierer von dem SOCKS-Proxy haben mir erzählt das ein frisch installiertes Windows 7 mit dessen Default-IE erfolgraich als Client getestet wurde, auch die Windows-System-Dienste (Update u.a.) sind wohl anständig gelaufen.

Für mich bedeutet dass das ich das aktuelle Projekt jetzt eben mit Chromium als Client durchziehen werde, ab und an mal was neues ist ja auch mal interessant.

Grüße
Erik

Hallo,

Zitat von Dr. Evil

Getestet hab ich das gestern auf einem aktuellen Gentoo (amd64~) mit dem neuesten Firefox Nightly.

Danke, ich versuche das als Bug bei Mozilla zu platzieren, hoffentlich wird dieses Thema dann dort auch wirklich mal ernsthaft angegangen.

Zitat von vincent001

Du willst mir also allen Ernstes erzählen, dass dort in 20 Jahren auch noch ein FF 20 und ein Kubuntu 10.04 laufen soll?

Ja, ich hab auch vor noch gar nicht so langer Zeit für Maschinen mit DOS oder Windows 95 programmiert. Mit OS/2 hatte ich es ebenfalls schon mal zu tun. Manche Industrieanlagen haben eine Lebenserwartung von über 50 Jahren und daran wird sich auch nichts ändern nur weil die Computerindustrie extrem schnelllebig ist. Gerade wegen der schnell alternden Software ist ja ein gutes Proxy von enorm hoher Wichtigkeit um die alte Software eben möglichst effektiv gegenüber der sich weiterentwickelnden Umwelt abzuschotten. Das Proxy ist auch so konzipiert das es möglichst einfach gegen ein neues Modell, das dann der sich ändernden Umwelt gewachsen bleibt, ersetzt werden kann.

Grüße
Erik

Hallo,

Zitat von Dr. Evil

Ich habe gerade mal ein bisschen rumprobiert, lokal einen SOCKS-Proxy mit "ssh -D [::1]:1234 host" gestartet. Firefox will sich zum Verrecken nicht damit verbinden. (Chrome dagegen kann's.) Ich stelle um auf IPv4 (127.0.0.1 statt [::1]) und es geht. In Wireshark sehe ich, dass Firefox nichtmal versucht irgendeine Verbindung aufzumachen. Ich fürchte da kann man nichts machen, außer einen Bug in Bugzilla aufzumachen.

endlich mal jemand der das Problem nachvollziehen kann. Auf welchem OS und mit welcher Firefox-Version hast Du dieses Problem?

Zitat von Dr. Evil

Zum Thema Namensauflösung: wenn du die Einstellung network.proxy.socks_remote_dns auf true setzt, sollte Firefox die DNS-Anfragen über den Proxy abwickeln.

Ich fürchte das liegt wohl auch am PAC-Script selber (ich gehe davon aus das Du die IPv6-Adresse im UI-Menü für die Internetverbindung direkt eingegeben hast, hier ist die Einstellung das Firefox selber ermitteln soll ob ein Proxy vorhanden ist was ansich ja auch klappt), wenn die Funktion 'isInNet' im ersten Parameter einen normalen Domain-Namen bekommt dann muss für diesen natürlich eine DNS-Abfrage gestartet werden um die IP-Adresse zu ermitteln (bevor überhaupt klar ist ob für die Verbindung zu diesem Host der Proxy benutzt werden soll), das heist ich muss in dem Script zuerst ermitteln ob in der Variable Host bereits eine IP-Adresse in Textform drin ist (der User könnte ja eine eingegeben haben) oder ein Domain-Name und dann 2 getrennte Pfade benutzen um zu ermitteln ob der Proxy benutzt werden soll oder nicht.

Zu den benutzten Versionen kann ich nur sagen das es sich hier um eine Industrieanlage (mit eigenen Netzwerk) handelt die mindestens noch 20 Jahre (weitestgehenst) unverändert laufen soll und da ist die langfristige Lieferbarkeit der Komponenten wichtiger als alles andere, in diesem Fall ist das limitierende Bauteil die CPU (PentiumM-Reihe) die noch kein PAE unterstützt und damit eine neuere Kubuntu-Version als 10.4 ausschliesst. Aber der Hersteller sicher eben eine lange Lieferbarkeit zu und damit war die Entscheidung gefallen (vor Jahren als die Anlage konzipiert wurde).

Zitat von .Hermes

Was hat SOCKS mit dem Proxy zu tun?

SOCKS ist ein Proxy-Protokoll mit dem der Client das Proxy bedienen kann, ist letztendlich eine Art Remote-Socket-API mit der sich das eine öffentliche Interface des Proxy-Servers von mehreren Clients aus benutzen lässt. Schau mal hier http://en.wikipedia.org/wiki/SOCKS#Com…o_HTTP_proxying, SOCKS kann auch UDP-Trafik (z.B. für SIP-Telefonie) oder TCP-Server-Sockets managen. Über SOCKS kann man also quasi jedes IP-basierende Protokoll leiten, solange die Client-Applikation das unterstützt (offiziell kann Firefox SOCKS), mit einem HTTP-Proxy sind die Möglichkeiten doch recht begrenzt (die typischen File-Sharing-Programme laufen z.B. nicht über HTTP-Proxys aber meistens können diese Programme SOCKS).

Grüße
Erik

Hallo,

Zitat von Boersenfeger

Vom Problem bzw. dessen Lösung habe ich leider keine Ahnung.

das ist sehr bedauerlich. Das Thema mit IPv6 und dem PAC-Script scheint durchaus noch in Entwicklung zu sein, man findet im Mozilla-Bug-Tracker doch einige Bugs von denen offensichtlich ein paar bis heute nicht behoben sind. Mit einem reinen IPv6-Netzwerk bin ich wohl trotz der "vollständigen" IPv6-Unterstützung in Firefox der gegenwärtigen Zeit etwas voraus. :-??
Hat den noch niemand z.B. mal ein Firmen-Netzwerk (dort sind ja auch Proxys üblich, manchmal sogar richtige SOCKS-Proxys) auf IPv6 umgestellt?
Gibt es den wenigstens irgendwo ein konkrete Übersicht ab welcher Firefox-Version welche Protokoll-Komponente per IPv6 richtig (oder wenigstens hoffentlich) funktioniert?
Auch eine halbwegs brauchbare Beschreibung der tatsächlichen PAC-Script-Fähigkeiten des Firefox wäre sehr wünschenswert, hierzu hab ich auch keine konkreten Informationen gefunden was genau der Firefox ab welcher Version unterstützt.

Ich schätze mal für dieses Thema muss ich den direkten Kontakt zu den verantwortlichen Programmieren suchen.

Danke für Eure Hilfe!

Grüße
Erik

Hallo,

ich habe hier ein Netzwerk in dem nur IPv6 gesprochen wird und da gibt es einen SOCKS5-Proxy der die Verbindung ins Internet herstellt. Die wpad.dat wird von Firefox auch korrekt gefunden (so wie es das "Web Proxy Autodiscovery Protocol" vorgibt) aber die Zeile

return "SOCKS5 [Proxy-IPv6-Address]:Proxy-Port";

scheint Probleme zu verursachen denn Firefox versucht noch nicht einmal eine TCP-Verbindung zu dem Proxy aufzubauen wenn ich eine nicht-lokale Seite ansteuern möchte. Lokale Seiten funktionieren einwandfrei, egal ob per Host-Name oder per IPv6-Adresse.
Wenn ich in der Script-Zeile oben anstatt der IPv6-Adresse des Proxy dessen Host-Name einsetze startet Firefox nur DNS-Abfragen für den A-Record die vom lokalen DNS-Server zwar trotzdem mit einem AAAA-Record beantwortet werden aber das wirkt nicht. Die DNS-Abfragen für den eingegebenen Domain-Namen (z.B. google.de) werden immer mit 2 DNS-Anfragen (nach AAAA und A) bedacht aber für den Proxy scheint Firefox unbedingt auf IPv4 zu bestehen aber das gibt es in dem Netzwerk nicht mehr.
Das zweite Problem ist das Firefox überhaupt DNS-Abfragen an den lokalen DNS-Server für die externen Domains schickt (da kommen natürlich nur "Name not found" Antworten zurück) anstatt die Namensauflösung dem Proxy zu überlassen.

Wie schaffe ich es das Firefox 20 einen SOCKS5-Proxy per IPv6 anspricht?
Wie kann man Firefox es abgewöhnen die Namensauflösung selber zu machen und das dem Proxy zu überlassen?

Mit Chromium 25 geht der Internetzugriff korrekt vonstatten.
Mein OS ist Kubuntu 10.04.

Grüße
Erik