Hallo Martin,

Eingeklappt wird der Thread ggfls auch, und die title-Infos werden auch geupdated.

Okay, das ist wohl neu. Mal beobachten. ;-)

bei mir tut sich da nichts. Ist das etwa an die Config-Option "Neue Nachrichten via Javascript nachladen" gekoppelt, die ich deaktiviert habe? Dann wäre es zumindest logisch, dass ich keinen Unterschied bemerke.

Jain. Diese Option schaltet tatsächlich nur das Nachladen via JS aus. Aber die Option „Mit JavaScript über neue Beiträge informieren“ schaltet die ganze Websocket-Verbindung und damit alle server-side Events ab. Ich denke, dass du diese Option eingeschaltet hast.

LG,
CK

Hallo,

ich habe soeben eingebaut, dass die Thread-Liste sich jetzt auch beim Lesen updated. Besucht mal also eine Nachricht, so wird die jetzt ohne Reload in der Liste als gelesen markiert.

das war aber bisher auch schon so.

Definitiv nicht, nein.

Es wird jetzt :visited (fast) genau so gestyled wie die Gelesen-Markierung, wenn du das meinst; dadurch hat es den Anschein, dass die Gelesen-Markierung auch ohne Reload wirkte.

dann liegt es daran, okay. Ich bin natürlich nur nach dem visuellen Eindruck gegangen, ein anderes von außen sichtbares Merkmal habe/hatte ich ja nicht.

So long,
 Martin

Hallo

Mir ist am Wochenende mehrfach (etwa zehn Mal) auf zwei Linux-Rechnern der Firefox abgeraucht und hat dabei die Desktop-Sitzung angehalten [^1]. Jedesmal, wenn das passierte, wollte ich ein Posting im SelfHTML-Forum aufrufen. Ein paar mal poppte nach ein paar Minuten die Meldung auf, dass ein Skript, nämlich das des Selfforums, einen Fehler verursacht hätte. Diesen Fehler habe ich an diesem Wochenende erstmals so beobachtet [^2].

Das will ich nicht ausschliessen, allerdings habe ich das nicht reproduzieren können. Hast du eine Idee was du getan hast um das zu provozieren? Reproduzierbarkeit wäre schon ziemlich nett... ;-)

Ich habe jeweils ein Posting aufgerufen. Punkt. Toller Fehlerbericht, nicht wahr? ;-)

Auf einem der Rechner (HP-Notebook, 4GB RAM, 64-Bit-Dual-Core, Ubuntu 15.10) wollte ich in mehreren Fällen, während des Aufrufs der neuen Seite den Tab wechseln. Offen waren zu diesem Zeitpunkt 13 Tabs. Auf dem anderen Rechner (PC, 8 GB RAM, 64-Bit-Quad-Core, Ubuntu 14.04) mit vier offenen Tabs und ohne akuten Tabwechsel war es exemplarisch der Aufruf des Eröffnungspostings über das Skript zum Sonntag, welches mir zweimal im Abstand von etwa fünf Minuten den Browser killte. Ein dritter Aufruf des Postings etwa zehn Minuten später funktionierte offensichtlich fehlerfrei.

Mit mehr Informationen kann ich aus dem Stehgreif erstmal nicht dienen.

Tschö, Auge

Hallo

... weder ..., noch mir keine Notizen über die in der Meldung genannte Programmzeile gemacht.

Na, dann spricht doch nichts dagegen, diese Notizen nicht zu verheimlichen ;p

© Superbass / CC-BY-SA-3.0 (via Wikimedia Commons)

Das kommt davon, wenn man bei der Satzumstellung nicht aufpasst …

Tschö, Auge

Hallo

Mir ist am Wochenende mehrfach (etwa zehn Mal) auf zwei Linux-Rechnern der Firefox abgeraucht und hat dabei die Desktop-Sitzung angehalten. Jedesmal, wenn das passierte, wollte ich ein Posting im SelfHTML-Forum aufrufen.

kleiner Tipp am Rande: Lass mal im Hintergrund, aber sichtbar (ideal wäre ein zweiter Bildschirm), in einem Konsolenfenster 'top' mitlaufen und beobachte a) den von Firefox belegten Arbeitsspeicher und b) die Aktivität des kswapd.

Hmm, endlich mal ein richtiger Grund, mich zu überwinden, den Schreibtisch aufzuräumen und den 24-Zöller als Zweitmonitor in Betrieb zu nehmen. :-)

Mir sind nämlich solche Ausreißer des Firefox auch schon aufgefallen (wenn auch nicht hier im Forum, dafür nutze ich idR Opera). Der belegt über längere Zeit immer mehr und mehr Speicher (2GB allein für FF sind keine Seltenheit) …

Dass der Firefox Speicher frisst, wie Kinder Schokolade, ist ja nichts Neues. Dass der dabei aber das ganze System anhält und mir Mate als Konsequenz mit Marco ein eher von Windows bekanntes Fenster vorblendet, das mich fragt, ob ich auf das nicht antwortende Programm warten oder es abwürgen will, hatte ich noch nicht.

… und löst dadurch irgendwann minutenlange "Orgien" des swap-Daemons aus, die natürlich auch durch die exzessive Festplatten-Aktivität auffallen - und in der Zeit geht dann buchstäblich nichts mehr.

Wie gesagt, das kenne ich grundsätzlich, es hatte aber nie die von mir am Wochenende beobachteten Konsequenzen**[edit], zumal es die (von mir undokumentierte) JS-Fehlermeldung gab[/edit]**.

Wenn das der Grund für die Hänger ist, kann CK aber meines Erachtens nichts dagegen tun - das ist ein reines Firefox-Problem und AFAIS nicht vorhersehbar.

Das ist soweit klar.

Tschö, Auge

Tach,

Es hängt stark von deiner Internet-Verbindung ab, wie schnell oder langsam das ist. Bei einer schnellen Internet-Verbindung ist es auch schnell geupdated ;-)

schon klar, aber viel schnelleres Internet als hier direkt am DFN bekomme ich wohl in nächster Zeit nicht, der überwältigende Teil der HTTP-Verbindung ist auch mit Warten auf den Server beschäftigt (nicht dass ich 400ms als besorglich lange einstufen würde, aber gegen 4ms Übertragungszeit spielt es nicht so die Rolle); ich muss auch zugeben, dass mein Rechner mal wieder am Limit ist und deshalb nochmal fast eine Sekunde braucht, bis DOMContentLoaded registriert.

Der Hintergrund ist, dass ich das Event über Websockets verschicke und bei Ankunft dann den neuen Thread vom Server hole.

Das dachte ich mir schon so in etwa.

mfg
Woodfighter