Es kommt vor, dass ein kleiner, banaler Fehler im Alltag empfindlich stört. Ein Sandkorn im Getriebe. Die Produktivität leidet. Vor allem aber stresst es, wenn die Arbeit unrund läuft.

Neulich mutierte Languagetool zu einem solchen Bremsklotz. Die Firefox-Erweiterung dieses Sprachhelfers korrigiert seit Jahren meine Texte fürs Blog und im CMS meines Arbeitgebers, in Google Docs und an vielen anderen Stellen. Er korrigiert nicht nur Orthografie, sondern spürt Grammatikfehler, fehlende Wörter, unvollständige Sätze und andere Bearbeitungsunfälle zuverlässig auf. Doch dummerweise funktioniert die Erweiterung in Firefox nicht mehr richtig (in Google Chrome gibt es das Problem nicht). Sie bremst den Browser aus und bringt ihn schliesslich zum Absturz. Exakt solche Hänger sind unerwünscht – vor allem, wenn man vor 15 Leuten eine Präsentation abhält.
Was tun? Eine Notlösung besteht darin, Languagetool nur bei Bedarf einzuschalten und nach jedem Korrekturlauf sogleich wieder zu deaktivieren. Das ist erstens mühsam, zweitens funktioniert der Trick nicht immer und drittens verpasst man die Deaktivierung vor der wichtigen Präsentation. Und viertens: WTF!
Den Hersteller juckt es nicht die Bohne
Meine Mails an den Kundendienst des Herstellers fruchteten [bis vor Kurzem] ebenso wenig wie die entsprechenden Kommentare auf der Bewertungsseite von Mozilla und mein Blogpost zum Thema.
Was tun? Eine gleichwertige Alternative gibt es nicht. Die bekannteste Ausweichlösung wäre Grammarly, aber ist auf Englisch ausgelegt und liefert in Deutsch nur mässige Resultate. Duden Mentor ist ein Drittel teurer und Scribbr bietet keine Browser-Erweiterung an (respektive nur fürs Generieren von Zitaten).
Stattdessen könnten wir auf die Idee eines Downgradings verfallen: Wir installieren die ältere Version, die problemlos funktionierte. Das funktioniert bei Firefox maximal einfach: Wir öffnen die Versions-Historie für Languagetool und klicken bei Version 9.0.1 vom 21. Juli 2025 auf Herunterladen (die neuere Version 10.0.9 vom 9. Januar 2026 ist offensichtlich die mit dem Speicherleck). Firefox tauscht das neue Modul sogleich durch das alte aus. Und siehe da: Die Variante vom Sommer des Vorjahres arbeitet so zuverlässig wie erhofft – Mozillas Warnung zum Trotz, man solle gefälligst immer die neueste Version verwenden.

«Geht nicht. Dumme Idee. Lass es bleiben.»
Damit ist das Problem leider erst halb gelöst. Firefox prüft Erweiterungen regelmässig und automatisch, und bringt die vermaledeite Version 10.0.9 ungefragt zurück. Wir müssen den Downgrade daher täglich vor Arbeitsbeginn wiederholen. Oder uns eine Methode ausdenken, wie wir die automatische Aktualisierung verhindern. Natürlich möchten wir das nur für Languagetool tun und nicht für alle anderen Plug-ins. Denn wenn wir die alle veralten lassen, wäre das ein unvertretbares Sicherheitsrisiko.
Ist das möglich? Googles AI Mode äussert eine starke Meinung zu dieser Frage: «Geht nicht. Dumme Idee. Lass es bleiben.»
Falls wir diese Antwort nicht akzeptieren und auf herkömmliche Art weitersuchen, stossen wir auf mehrere Methoden. Eine wird mehrfach genannt, funktioniert jedoch nicht¹.
Ich verfiel auf die Kamikaze-Lösung, die Xpi-Datei für Languagetool im Profilordner unter extensions auf schreibgeschützt zu setzen: So würde sie durch das Update nicht ersetzt werden können. Eine gute Idee? Mutmasslich nicht.
Drei Methoden, um das kaputte Update fernzuhalten
Es gibt mehrere weitere, potenziell «anständig» funktionierende Möglichkeiten:
- Wir installieren das Plug-in manuell via Sideloading. Auf diese Weise geht die Verbindung zum Store verloren, was die automatische Aktualisierung verhindert.
- Wir richten eine Enterprise-Policy ein.
- Wir schauen uns die Xpi-Datei der aktuellen Version 10.0.9 an und probieren, sie mittels Vibe-Coding zu reparieren.
Die Methode drei wäre nachhaltig. Aber ohne Lohn anderer Leute Arbeit verrichten? Muss nicht sein.
Der vielversprechendste Weg ist Numero zwei. Anhand der Policy Templates finden wir heraus, wie eine solche Vorgabe gestrickt wird, und legen sie an². Und siehe da: Das führt zum Ziel: Mein Seelenfriede ist wiederhergestellt³.
Es braucht Eingriffsmöglichkeiten
Und die Moral von der Geschicht’? Es gibt mehrere: Erstens zeigt sich, wie fehleranfällig meine exakt auf die persönlichen Bedürfnisse zugeschnittene Arbeitsumgebung ist. Ein Sandkörnchen – und schon knirschte es im Getriebe.
Das zeigt zweitens die Abhängigkeit von ganz vielen Zahnrädern, die nahtlos ineinandergreifen müssen. Und drittens beweist es, wie wichtig es ist, dass wir selbst Hand an diese Maschinerie legen können. Wenn uns Browser, Betriebssysteme und Programme vollkommene Wartungsfreiheit versprechen und uns von jeglichen manuellen Eingriffen bewahren (und aktiv fernhalten), dann sind wir aufgeschmissen. Ansonsten – wie hier – greifen wir zu einer versteckten Expertenoption oder einem Kamikaze-Trick und retten den Tag. Merci, Firefox, dass du diese Tür offen hältst.
Nachtrag
Just, bevor dieser Blogpost online ging, zeigte mir die (in den Fussnoten erwähnte) Firefox-Erweiterung Extension Update Checker an, dass die Version 11.0.1 von Languagetool verfügbar ist, datiert am 19. Mai 2026 (letzte Woche war sie allerdings noch nicht online, siehe Screenshot oben). Wie gut sie das Problem löst, bleibt abzuwarten.

Fussnoten
1) Dieser untaugliche Ansatz findet sich in der (inzwischen veralteten) Mozilla-Knowledge-Base. Er basiert auf einem Konfigurationseintrag, der das Update für eine bestimmte Erweiterung verhindert¹, aber offenbar nur für die alten, mit der ominösen Version 57 abgeschafften Erweiterungen gilt. Konkret tragen wir via about:config den Eintrag extensions.{GUID-Nummer}.update.enabled in die Konfigurationsdatei ein. Da ich für Languagetool tatsächlich eine GUID fand und den Eintrag (als Bool) anlegen und auf False setzen konnte, war ich erst guter Hoffnung. Doch es klappte nicht. ↩
2) So sieht die Policy für Languagetool aus:
{
"policies": {
"ExtensionSettings": {
"languagetool-webextension@languagetool.org": {
"installation_mode": "allowed",
"updates_disabled": true
}
}
}
}
Die Add-on-ID lässt sich via about:supportherausfinden. Abgelegt wird die Datei mit dem Namen policies.json im Unterordner distribution im Programmverzeichnis von Firefox. In meinem Fall befindet sich das unter C:\Program Files (x86)\Mozilla Firefox\distribution. Es gibt dort bei mir auch bereits eine Datei policies.json, die vom Einsatz des Just-The-Browser-Tools herrührt (Die Browser in die Schranken weisen). Wir könnten die Ambition verspüren, diese beiden Dateien manuell zusammenzuführen. Oder wir machen es uns einfach und geben Claude den Auftrag, sie zu kombinieren.
Nach einem Neustart des Browsers prüfen wir mittels about:policies, ob die Vorgabe übernommen wurde. Falls das der Fall ist, sollte alles in Butter sein. ↩
3) Wenn der Hersteller ein weiteres Update liefert, das das Problem potenziell behebt, sollten wir das nicht verpassen und unsere Update-Verbots-Policy entfernen. Zur Überwachung der Updates verwenden wir Extension Update Checker. ↩