11 Reaktionen

Add-ons funktionieren seit Update auf Firefox 35 nicht? Lösung!

Geschätzte Lesedauer:

Mozilla hat vergangenen Dienstag Firefox in Version 35.0 veröffentlicht. Für manche Nutzer mit vom Standard abweichender Konfiguration haben einige Add-ons aufgehört zu funktionieren. Hier gibt es die Lösung.

Problem und Ursache

Mozilla hat am Dienstag Firefox 35.0 veröffentlicht. Manche Nutzer beklagten nach dem Update, dass einige Add-ons, unter anderem Adblock Plus / Edge, aufgehört haben zu funktionieren. Grund hierfür ist eine Änderung in Firefox 35 in Bezug auf IndexedDB, welche eben jene Probleme auslöst, sofern der Nutzer die versteckte Firefox-Einstellung dom.indexedDB.enabled auf false gesetzt hat. Standardmäßig steht dieser Schalter auf true, das heißt betroffen sind von diesem Problem ausschließlich Nutzer, welche zuvor selbst an den Einstellungen von Firefox herumgespielt oder ein Derivat installiert haben, welches diese von Mozilla nicht vorgesehene Einstellung als Standard definiert hat. Wie Firefox-Ingenieur Kyle Huey in Mozillas Bugtracker klargestellt hat, ist die Deaktivierung von IndexedDB keine von Mozilla unterstützte Konfiguration.

Lösung

Nichtsdestominder hat Mozilla das Problem zeitnah behoben, bereits in Firefox 36 wird dieses Problem der Vergangenheit angehören. In der Zwischenzeit können betroffene Nutzer das Problem umgehen, indem sie about:config in die Adressleiste eingeben, die Warnung bestätigen, nach dem Schalter dom.indexedDB.enabled suchen und diesen per Doppelklick wieder auf seine Standard-Einstellung true setzen.

via:
Dieser Artikel wurde von Sören Hentzschel verfasst.

Sören Hentzschel ist Webentwickler aus Salzburg. Auf soeren-hentzschel.at informiert er umfassend über Neuigkeiten zu Mozilla. Außerdem ist er Betreiber von camp-firefox.de, der ersten Anlaufstelle im deutschsprachigen Raum für Firefox-Probleme aller Art. Weitere Projekte sind firefox.agenedia.com, mozilla.de, firefoxosdevices.org sowie sozone.de.

11 Kommentare - bis jetzt!

Eigenen Kommentar verfassen
  1. Klaus Hartnegg
    schrieb am :

    Kein Wunder, dass das viele Nutzer abschalten. Anderenfalls kann jede Webseite ungefragt 25 Megabyte Daten auf der lokalen Festplatte abspeichern, ohne dass die Nutzer darüber auch nur informiert werden, geschweige denn zugestimmt haben.

    Die Firefox-Entwickler betonen, dass sie den Nutzern die Kontrolle zurückgeben wollen, und dann wundern sie sich, dass sie viele Nutzer haben, die solche unerwünschten „Features“ abschalten. Da braucht man doch kein Hellseher sein, um das vorhersehen zu können.

    Der Fehler in Firefox 35 war, dass Firefox diesen Speicher plötzlich auch selbst genutzt hat, obwohl der dafür nicht gedacht war, und dass der Abschalter auch dafür galt. Und obwohl das in der Testphase aufgefallen war, wurde die neue Version dennoch so veröffentlicht. Jetzt haben wir wieder mal 6 Wochen lang die Wahl zwischen Pest und Cholera (kaputt oder unsicher).

  2. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    Man wird auch nicht vor dem Anlegen jedes Cookies gefragt. Auch bei LocalStorage gibt es keine Nachfrage. Letzten Endes sind das alles nur Datenspeicher. Dass jede Webseite ungefragt 25 Megabyte Daten anlegen könnte, klingt furchtbar dramatisch, mehr aber auch nicht. Selbst wenn eine Webseite diese Menge an Daten anlegt, dann tut es damit längst noch keine zweite. IndexedDB ist ein Webstandard und ich sehe nicht, dass es Einstellungen für alle anderen Webstandards gibt, um sie zu deaktivieren, höchstens noch eine Weile nach der Einführung. Meiner Meinung nach sollte Mozilla die Einstellung komplett entfernen, wie es auch die ursprüngliche Intention des Tickets war, in dem es um die Behebung des in Firefox 35 aufgetretenen Problems ging. Der letzte Punkt ist Quatsch („unsicher“), oder welche Lücken sind bekannt, die nicht einmal Mozilla bekannt sind? Auch müssten wir uns vielleicht mal darüber unterhalten, was „viele“ bedeutet, da habe ich nämlich nach meiner Vorstellung des Wortes „viele“ meine Zweifel. Viel mehr ist es so, dass es Firefox-Derivate gibt, welche diese Einstellung per Standard verstellt haben, das dürfte häufiger der Fall sein als dass ein Nutzer ohne besonderen Bezug zu Webstandards eine versteckte Firefox-Einstellung sucht. Also der Kommentar hat wirklich mehr von Panikschüren als von einer Fakten-Darlegung. Und ich bin ein sehr großer Freund von Fakten.

  3. schrieb am :

    Soweit mir bekannt ist, besteht das Problem seit Firefox 27 – warum es sich gerade jetzt bei so vielen Nutzern manifestiert, ist nach wie vor unklar. Ich habe unter https://bugzilla.mozilla.org/show_bug.cgi?id=1122204#c5 eine Vermutung geäußert, mehr aber auch nicht. Dementsprechend stimmt die These von einer zeitnahen Behebung des Problems nicht wirklich. Vielmehr war das Problem mindestens seit Oktober bekannt (https://bugzilla.mozilla.org/show_bug.cgi?id=1079355), bloß nicht der Ausmaß davon. Der Patch war jedenfalls eine Woche vor Firefox 35 fertig, sonst wäre es für Firefox 36 vermutlich zu spät gewesen.

    Übrigens stimme ich zu, es gibt keinen prinzipiellen Unterschied zwischen indexedDB und Cookies. Ob 2 kB oder 25 MB – für den Nutzer ist das Letztere eher ein Vorteil, bei Cookies werden womöglich dieselben 25 MB auf dem Server gespeichert, wo man sie gar nicht mehr kontrollieren kann.

  4. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    Soweit mir bekannt ist, besteht das Problem seit Firefox 27 – warum es sich gerade jetzt bei so vielen Nutzern manifestiert, ist nach wie vor unklar. Ich habe unter https://bugzilla.mozilla.org/show_bug.cgi?id=1122204#c5 eine Vermutung geäußert, mehr aber auch nicht. Dementsprechend stimmt die These von einer zeitnahen Behebung des Problems nicht wirklich.

    Im Firefox-Support ist mir dieses Problem jedenfalls vor Firefox 35 nie untergekommen, das hat erst mit Firefox 35 angefangen. Dass der Kern des Problems schon älter ist, mag natürlich sein, aber irgendwas in Firefox 35 muss letztlich ausgelöst haben, dass es zu einem realen Problem wurde, welches einige Nutzer betrifft. Das ist für mich dann schon ein neues Problem und wenn es dann in Firefox 36 behoben ist, eine zeitnahe Behebung. 😉 Die Sache ist halt die, dass man nur die Probleme beheben kann, die als Problem bekannt sind. Was auch immer dieses Problem in Firefox 35 ausgelöst hat, das wird mit hoher Wahrscheinlichkeit seinen Weg über Nightly, Aurora und Beta gegangen sind, wenn ich jetzt mal nicht davon ausgehe, dass es eine Änderung mit spätem Beta-Uplift war. Was mich einmal mehr zu der Erkenntnis bringt, dass es viel mehr Leute bräuchte, die auch mal eine Vorabversion testen und Probleme melden… Denn wäre das Ausmaß dieses Problems auch nur annähernd bekannt gewesen, wäre das ganz bestimmt so nicht in der finalen Version passiert.

  5. schrieb am :

    Nutzer von Adblock Plus klagen leider schon seit längerer Zeit über Probleme mit ähnlichen Symptomen. Bis jetzt ließ es sich allerdings nie auf ein reproduzierbares Problem zurückführen. Also habe ich die (möglicherweise naive) Vermutung, dass es das Problem schon länger gab, es kommt bloß seit Firefox 35 öfter vor. Zumindest hoffe ich sehr, dass die Berichte über nicht reproduzierbares Komplettversagen von Adblock Plus mit Firefox 36 endlich ihr Ende finden.

  6. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    Ich drücke die Daumen, dass diese Berichte damit ihr Ende finden. Vielleicht braucht es manchmal einfach ein größeres Problem, damit das nicht ganz so offensichtliche Problem die notwendige Aufmerksamkeit erhält. 😉 Ich wäre sehr daran interessiert zu erfahren, wie es bzgl. Adblock und den Problemberichten nach dem Erscheinen von Firefox 36 aussieht. Vermutlich wird man das auch zunächst einige Wochen beobachten müssen, um zu einem Fazit zu kommen.

  7. schrieb am :

    Eventuell etwas OT aber dies hier ist der aktuellste Artikel wo es wenigstens etwas passt:
    Was gibt es denn in Firefox Release 36 für wichtige Änderungen welche jetzt auch schon – logischerweise – in der Beta 36 zu finden sind und auch schon seit dann ca. 2×6 Wochen (od. etwas kürzer) in der Nightly Version vorhanden waren?

    Hier passiert seit einiger Zeit folgendes, zuerst in der Nightly und nun seit V. 36 auch in der Beta: Firefox läuft, einige Tabs offen dann schicke ich das NB in den Standby. Anschließend öffnet Firefox keine Seiten mehr, obwohl für alle anderen Anwendeungen das Internet problemlos funktioniert. Warteanzeige ist zu sehen aber nix passiert und es kommt keine Fehlermeldung. Wenn ich jetzt Firefox schließe um ihn neu zu starten wird er aber nicht komplett beendet. Der Task bleibt mit komplett belegtem Speicher den Firefox auch vorher nutzte im TM. Und dort kann man ihn auch nicht beenden! So etwas hatte ich bisher bei noch keinem Programm.
    Und dieses Problem habe ich nun auch in der Beta. Irgend eine Idee?
    Ach so nach dem Update der Beta von 35 auf 36 meldete sich die Win Firewall als hätte ich ein neues Programm erstmalig gestartet was sonst bei einigen Firefox Updates schon der Fall war. Und dies war bei der Nightly vor ein paar Wochen auch der Fall.

    Hier mal der letze Crash Report https://crash-stats.mozilla.com/report/index/15c7530c-4706-46f6-b69a-57ea92150115
    Sehe da gibt es einen related Bug: Shutdown crash in mozilla::`anonymous namespace“::RunWatchdog(void*)

  8. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    Da hab ich keine Idee. Das Problem ist wohl, wie es sich am Ende des von dir verlinkten Bugs liest, dass die Signatur nicht speziell genug ist…

    This crash signature is the aggregate of many different issues. We need a fix for bug 1104317 before we can detangle them.

    In the meantime I’d like to request that people not post any more crash IDs in this meta-bug. Everyone’s got a different root cause, and we’re not going to get anywhere with a jumbled mess of conversations.

    https://bugzilla.mozilla.org/show_bug.cgi?id=1103833#c26

  9. Marc Senn
    schrieb am :

    Normaler PC selbst zusammengebaut. Win 8.1 Pro x64

    Also hab es gerade probiert mit FireFox 38a1 x64 aktuell mit dem letzten Sicherheitsupdates.
    Also ein paar Taps geöffnet in den Energiesparmodus, gleich wider zurück aus dem Modus und Browser bleibt stehe. 10 sek.. später Bluscreen das 2te mal hintereinander Getestet. Weil 1x könnte es auch Zufall sein aber nicht 2 mal. ^^

  10. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    @Marc Senn:

    Normaler PC selbst zusammengebaut. Win 8.1 Pro x64

    Also hab es gerade probiert mit FireFox 38a1 x64 aktuell mit dem letzten Sicherheitsupdates.
    Also ein paar Taps geöffnet in den Energiesparmodus, gleich wider zurück aus dem Modus und Browser bleibt stehe. 10 sek.. später Bluscreen das 2te mal hintereinander Getestet. Weil 1x könnte es auch Zufall sein aber nicht 2 mal. ^^

    Wenn du einen Bluescreen erhalten hast, dann wird da auch etwas gestanden haben, was sehr relevant für dein Problem ist. Was stand da?

  11. schrieb am :

    Interessant, wenn ich im laufenden Betrieb den WLAN Adapter trenne
    (netsh interface set interface WLAN Adapter Name disable)
    dann kommt es zu dem oben erläuterten Effekt. Was auch zusammenpasst denn bei Ruhezustand/Standby wird ja auch die Netzverbindung getrennt.

Und jetzt du! Deine Meinung?

Erforderliche Felder sind mit einem Asterisk (*) gekennzeichnet. Die E-Mail-Adresse wird nicht veröffentlicht.
  1. Nach Absenden des Kommentar-Formulars erfolgt eine Verarbeitung der von Ihnen eingegebenen personenbezogenen Daten durch den datenschutzrechtlich Verantwortlichen zum Zweck der Bearbeitung Ihrer Anfrage auf Grundlage Ihrer durch das Absenden des Formulars erteilten Einwilligung.
    Weitere Informationen