Beiträge von XtC4UaLL

Also ich würde - ich mache mal einfach mit im Rätselraten - Firebug deaktivieren.

Zitat von BeeHaa

Jetzt warte ich nochmals 1 Monat bis die Geschichte mit OOPP und <embed> behoben wird. Die Updatemodalitäten bei Mozilla gehen mir langsam auf den Keks.

Es steht jedem frei, die Nightly Builds des Release Zweigs zu nutzen:
http://ftp.mozilla.org/pub/mozilla.or…lla-1.9.2-l10n/
Dann erhältst man die Fixes am Folgetag nach dem Checkin.

Jedes Release geht auch durch die QA - und das braucht Zeit. Vor allem wenn es Releases zweier oder dreier Zweige (fast) gleichzeitig gibt (1.9.1, 1.9.2 und 2.0). Du könntest nun das Mozilla um die Ohren hauen und sagen: "dann stellt halt mehr QA Leutchen ein" damit das schneller von statten geht, aber dem ist halt nicht so.

Falls du wirklich an Verbesserungen/konstruktiver Kritik an dem Release-Prozess interessiert bist, schreibe Christian Legnitto (als Verantwortlichen) eine Mail oder erstelle einen Thread in http://groups.google.com/group/mozilla.dev.planning.

Und das mit dem "alle zwei Monate" ist auch nicht korrekt - es gibt keine feste Regel.

Hmm, bei mir war das in den letzten Jahren immer so, dass "user.js geht über alles" und überschreibt prefs.js Inhalte ...

Sieht nach einer Same-Origin-Prüfung laut der Meldung aus.
Welche ist die letzte Firefox Version die bei dir klappt, welche die erste die o.g. Meldung ausgibt?

Alternativ müsste auch folgendes funktionieren:
* Firefox + Soll-Erweiterung installieren
* Soll-Einstellungen der Erweiterung vornehmen
* die Einstellungen der Erweiterung aus der prefs.js-Datei herauskopieren
* eine user.js-Datei mit dem Inhalt der kopierten Einstellungen erstellen
* diese user.js-Datei ist dann zusammen mit der Erweiterung zu deployen, z.B. indem man Erweiterungsordner und user.js-Datei nach %FirefoxInstallationsOrdner%\defaults\profile kopiert.

Ist aber ungetestet.

Errm, nö. Der Verzeichnisname wäre dann anders.
Die Datei ist Bestandteil von Fx und kümmert sich z.B. um die Steuerung des Löschens von Daten beim Schließen von Firefox ("neueste Chronik löschen") oder auch den Privaten Modus.

Wenn ein "Zeitüberschreitungsdialog" erscheint, dass ein JS Script (Fx-intern/Erweiterung) zu langsam ausgeführt wird, so ist es zu 99,99% immer auf eine externe Einwirkung z.B. eines Sicherheitsprogramms zurückzuführen, was die Ausführung solcher Dateien überwacht.

Was für Scripte in Webseiten toll sein kann, ist lokal für den Fx schlecht ;-).

Edit: Zeile 85 deutet übrigens darauf hin, dass beim Beenden von Firefox der Cache gelöscht werden soll.

Der Dialog erklärt aber nicht die eigentliche Ursache, dass mit der Zeit Fx langsamer wird - es ist ggf. nur ein weiteres Symptom der gleichen Ursache ("Sicherheitsprogramm" oder sonstwas).

Da ein zeitlicher Zusammenhang deiner Probleme mit dem Update besteht *und* du ein Sicherheitsprogramm angibts => https://support.mozilla.com/de/kb/Kaspersk…y+konfigurieren

Zitat von BeeHaa

Unter https://bugzilla.mozilla.org/buglist.cgi?qu….9.2%3A.8-fixed waren bis gestern 10 Stück aufgelistet. Zarro boogs. Was soll denn der Quatsch?

Wie oft soll ich Dir das denn noch erklären? ;-P
3.6.8. gab es wegen https://bugzilla.mozilla.org/show_bug.cgi?id=575836.
Der Bug ist in der Bugzilla Gruppe Core-Security.
Nur Mitglieder dieser Gruppe können den Report aufrufen, nur Mitgliedern dieser Gruppe wird der Report als Suchergebnis (mit) angezeigt.
Deshalb gibt der in den Release Notes angegebene Suchstring auch eine "leere" Liste.
Da 3.6.8. nun eingeschoben wurde, sind die .8-fixed Bugs in .9-fixed übergegangen.
Per https://bugzilla.mozilla.org/buglist.cgi?qu….9.2%3A.9-fixed kannst Du nun Deine (momentan) 10 Reports ansehen.

Alles klar?

Errrm, ist das nicht lediglich ein Hinweis, der sicherstellen soll, dass das "Bilder anzeigen lassen" eingeschaltet ist damit der Captcha Kram funktioniert?

Die Congstar Login-Geschichte hat nichts mit dem Firefox oder einem anderen Browser zu tun, sondern mit einer Systemumstellung seitens Congstars, seit deren Ende viele liebe Kunden (inklusive mir) sich nicht mehr einloggen können.

Okay
Einer der folgenden Checkins käme in Frage:
https://bugzilla.mozilla.org/buglist.cgi?qu…32&product=Core
Entweder ist unter "Depends on" in den einzelnen Reports bereits einer vorhanden, welcher dein Problem beschreibt oder du erstellst einen neuen mit der Information, welches Nightly Build das letzte problemlose und das erste problembehaftete ist - auf dem 1.9.2 Zweig.

Interessant wäre auch, ob es an einem bestimmten Favoriteneintrag liegt.
Toll wäre folgendes:
1. Favoriten sichern
2 .die Hälfte deiner Favoriten löschen
3. Import in Fx durchführen

Kommt ein Crash => 2. wiederholen
Kommt kein Crash => die gelöschte Hälfte wiederherstellen und die andere Hälfte löschen.

Wiederhole den Importvorgang bis du die zum Absturz bringenden Favoriten ausmachen konntest.

Dann gibt hier Rückmeldung

Der "F6"-Bug ist https://bugzilla.mozilla.org/show_bug.cgi?id=249735 welcher der breiten Masse erst mit der "Tabs oben"-Einstellung auffiel.

Müsste dann ja ein Widget Win32 Bug aus der "Fixed Liste" sein.
Könntest ja mal nachforschen, ob ein Nachfolgereport als Regression erstellt wurde oder den Regressionszeitraum auf dem 1.9.2-Zweig suchen.

Der Absturz wird durch das hängende Adobe Flash Plugin verursacht.
Bitte alte Flash Versionen durch neuere ersetzen.

Die Ursache liegt zu 99% an einer Drittanwendung ("Sicherheitsprogramm") welche den Zugriff von Mozilla Firefox auf Internetseiten blockiert.
Es wäre einmal interessant zu wissen, ob Du auf die Weboberfläche Deines Routers - so vorhanden - zugreifen kannst.

Zitat von Nub

Welche Vorteile ergeben sich denn aus dieser Änderung?

https://developer.mozilla.org/en/XPCOM/XPCOM…_2.0#But_why.3f

* schnellerer Anwendungsstart
* notwendige Voraussetzung für die kommende prozessuale Trennung Chrome UI <-> Content (wird insbesondere für Fennec benötigt)
* Installation von Erweiterungen ohne Neustart

Also,
mit Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.11) Gecko/20100701 Firefox/3.5.11 ID:20100701023340
werden die grünen Rahmen sofort geladen und beim Anklicken ist kein "Flackern" vorhanden.

mit Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.7) Gecko/20100701 Firefox/3.6.7 ID:20100701024234
werden die grünen Rahmen erst nach einem "Mouse-Over" geladen und es ist beim Anklicken ein "Flackern" des DIV-Containers (?) vorhanden.

mit Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100711 Minefield/4.0b2pre ID:20100711040735
werden die grünen Rahmen erst nach einem "Mouse-Over" geladen und beim Anklicken ist kein "Flackern" vorhanden.

Also Änderungen im Verhalten der Gecko-Versionen sind schon ersichtlich. Schön wäre ein reduzierter Testcase, damit man das Problem mal in Bugzilla suchen/einstellen könnte.

So wie es in den Absturzmeldungen dargestellt ist, gar nicht, da der Absturzmelder die Aufgabe hat, eine Momentaufnahme zum Absturzzeitpunkt geben.
Anwendungsunabhängig bietet sich der Windows Taskmanager oder z.B. der Process Explorer an.

Als Schuss ins Blaue würde ich sagen, dass eine externe Anwendung das Laden von CSS-Dateien unterbindet - z.B. der McAfee Kram.