Ein neuer Artikel wurde veröffentlicht:
Artikel lesen: „Mozilla veröffentlicht Firefox 157 mit Nova-Design“
Ja. Abgesehen von der Menüleiste, die auf macOS vom Betriebssystem und nicht von Firefox dargestellt wird, ist die Firefox-Oberfläche von der grundlegenden Struktur her identisch auf allen Desktop-Betriebssystemen.
Ein neuer Artikel wurde veröffentlicht:
Artikel lesen: „Mozilla investiert weitere fünf Millionen USD in Mozilla Data Collective“
Sorry, deine Beiträge bleiben verwirrend. Auch dieser Beitrag erklärt nicht deine Aussage „Nicht anders als wie unter Windows” (sic!), weil es diese Option unter Windows überhaupt nicht gibt. Und nein, der Screenshot in meinem Artikel zeigt die Checkbox, aber nicht alle Auswirkungen dieser Option. Es gab auch gar keine „Zweifel”, von denen du jetzt sprichst. Webmark schrieb lediglich, es in Ruhe auf sich zukommen zu lassen und gespannt zu sein. Und natürlich muss man genau das tun, wenn man vorher keine Vorab-Version oder unfertige Implementierung testen möchte.
Was dein Artikel darstellt, ist daher auch nur eine Übersicht, was Mozilla gemacht hat, aber nicht, welchen Zweck es verfolgt.
Doch, der Zweck steht im Artikel:
Open-Source-Modelle stehen zwar längst zur Verfügung. Ein solches Modell sicher, zuverlässig und in bestehende Systeme integriert produktiv einzusetzen, erfordert aber häufig ein spezialisiertes Entwicklerteam und mehrere Monate Arbeit. Genau an dieser Stelle setzt die Initiative an: Unternehmen und andere Organisationen sollen ein einsatzbereites KI-Paket erhalten, das sie privat und unter eigener Kontrolle betreiben können. Damit sollen sie weder selbst ein komplexes Gesamtsystem entwickeln noch vollständig von proprietären KI-Diensten abhängig sein, bei denen jede Anfrage Kosten verursacht.
Und danach wird dies weiter im Detail ausgeführt und ein konkretes Anwendungsbeispiel genannt.
Ich mag nicht endlos Links anklicken, um die Essenz lesen zu können.
Musst du ja auch nicht, da ich genau das übersetzt und zusammengefasst habe, was Mozilla auf seinem Blog geschrieben hat. Mein Artikel basiert auf Mozillas Ankündigung.
Ich wollte doch nur wissen, welche Vorteile Open Source AI mir als Endnutzer (!) bringt gegenüber etablierten KI - und zwar mit Infos über den Tellerrand hinaus.
Du als Endnutzer bist, wie ich bereits schrieb, überhaupt nicht das Ziel. Es geht explizit um eine Lösung für Unternehmen, Organisationen und Behörden.
Ach ja. Derzeit ist die Politik hier und da mehr als involviert. Ein Blick über den Tellerrand hinaus schadet nicht, schon gar nicht bei EU<> Kanada und USA<>Kanada. Mag für dich unwichtig zu sein, aber der "Knaller" regiert noch zwei Jahre nach den Midterms. Das kann und sollte man nicht ignorieren, weshalb ich verstärkt auf europäische Optionen setze, sei es Mistral, oder Quant.
Es geht nicht darum, ob das für mich wichtig oder unwichtig ist. Es spielt für den Einsatz schlicht und ergreifend keine Rolle, in welchem Land die Produkt-Entwicklung stattfindet. Und eine Regierung mag den Zugriff auf eine Cloud-KI einschränken können, aber nicht den Zugriff auf lokale KI.
Ich verstehe auch die erneute Erwähnung von Mistral am Ende nicht, weil es hier wie gesagt nicht um eine Alternative zu Mistral oder anderen LLMs geht.
Das ist in anderen Bereichen ja auch meistens so, dass Spezialisten im jeweiligen Bereich besser als Allrounder sind, die „alles” abdecken. 
Ich habe mein Plus-Abo dazu genutzt.
Zum wiederholten Mal: Es geht nicht um Firefox. Ich verstehe nicht, was die ständige Reduzierung von Mozilla auf Firefox soll. Nicht einmal ansatzweise alles, was Mozilla macht, spielt eine direkte oder indirekte Rolle für Firefox. Der Bezug zu Kanada ist schlicht und ergreifend, dass Mila aus Kanada kommt. Und worum es bei dieser Initiative geht, steht wie gesagt im Artikel. Mehr möchte ich dazu nicht mehr schreiben.
Und wo ist jetzt das Problem?
"Option" ist dein Stichwort!
Sieht etwas krumm aus wegen eigenem CSS, aber gegenüber dem Bild von Sören ist es doch ersichtlich
Richtet sich diese Erklärung an dich selbst? Denn folgende Aussage kam von dir:
Nicht anders als wie unter Windows
Niemand sonst hatte in diesem Thema ein Unklarheit diesbezüglich geäußert. 
Um die sehr komplexen Zusammenhänge verständlicher zu machen, wieso es ein Joomla-Problem und kein Firefox-Bug in dem Sinn ist, obwohl nur Firefox betroffen ist, habe ich das GPT 5.6-Sol analysieren und erklären lassen:
Der Auslöser war sehr wahrscheinlich Firefox Bug 543435 („sync-about-blank“), der mit Firefox 148 aktiviert wurde. Joomla umgeht dabei aber nicht einfach einen Firefox-Bug. Vielmehr hat die Firefox-Änderung eine Timing-Annahme in Joomlas TinyMCE-Integration offengelegt, die mit dem neuen – beabsichtigten – iframe-Verhalten nicht mehr funktioniert.
Was Firefox 148 geändert hat
Der entscheidende Firefox-Change ist Mozilla Bug 543435 – sync-about-blank. Die Änderung war ursprünglich sogar schon für Firefox 147 vorgesehen, wurde dort aber zurückgenommen und blieb dann für Firefox 148 aktiviert. bugzilla.mozilla.org
Firefox 148 änderte konkret das Verhalten des initialen about:blank-Dokuments eines iframe. Mozilla beschreibt es in den Firefox-148-Developer-Release-Notes so: Das initiale about:blank wird jetzt synchron geladen. Firefox erzeugt nicht mehr zunächst ein leeres Dokument und ersetzt dieses anschließend asynchron durch ein zweites about:blank-Dokument. Dementsprechend kann auch das zugehörige load-Event synchron auftreten. MDN Web Docs
Das ist ziemlich genau die Art Änderung, die den Joomla-Code trifft.
Mozilla wusste übrigens schon vor dem Release, dass diese Änderung bestehenden Code durcheinanderbringen kann. In Bug 1994668 heißt es ausdrücklich, dass ein häufiges Muster darin besteht:
iframe erzeugen → load-Listener setzen → iframe ins DOM hängen → src setzen
Mit synchronem about:blank kann dann plötzlich ein unerwartetes load-Event vor der eigentlich beabsichtigten Navigation auftreten. Mozilla musste deshalb sogar eigenen Firefox-Code anpassen. bugzilla.mozilla.org
Was Joomla gemacht hat
Der relevante Joomla-Code hatte bereits eine Sonderbehandlung für TinyMCE-iframes. Hintergrund ist, dass Joomla einen TinyMCE-Editor neu initialisieren möchte, wenn dessen iframe durch DOM-Manipulationen – beispielsweise beim Verschieben eines Subform-Elements – seinen Inhalt verliert bzw. neu geladen wird.
Dafür hing Joomla einen load-Listener an den iframe, der dann debounceReInit(...) aufruft. GitHub
Genau das wird mit dem neuen Firefox-Verhalten gefährlich:
Firefox erzeugt/lädt initiales about:blank synchron → load → Joomla interpretiert das als Reload des bereits initialisierten iframe → debounceReInit() → TinyMCE wird neu initialisiert → neues iframe/about:blank → load → Reinitialisierung → …
Das erklärt das beobachtete endlose Flackern beziehungsweise Reloaden sehr gut.
Der Fix aus Joomla PR #46889 macht deshalb etwas Entscheidendes: Joomla wartet nun sowohl auf TinyMCE load als auch auf init. Erst nachdem beide Initialisierungsereignisse stattgefunden haben, wird der eigentliche Listener installiert, der spätere iframe-Reloads als Anlass für debounceReInit() betrachtet. Falls das iframe zu diesem Zeitpunkt selbst noch nicht vollständig geladen ist (readyState !== 'complete'), wartet Joomla zusätzlich dessen ersten load ab und installiert erst danach den Reload-Listener. GitHub
Das ist also im Wesentlichen eine Unterscheidung zwischen:
„Der iframe lädt gerade zum ersten Mal als Teil der TinyMCE-Initialisierung“
und
„Der fertig initialisierte iframe wurde später tatsächlich neu geladen.“
Firefox-Bug oder Joomla-Bug?
Ich würde es eher als Web-Compatibility-Fix auf Joomla-Seite infolge einer absichtlichen Firefox-Verhaltensänderung einordnen.
Der stärkste Hinweis darauf ist, dass Bug 543435 selbst kein versehentlicher Firefox-Regressionsbug ist. Er ist als RESOLVED FIXED für Firefox 148 geführt, und Mozilla hat die Änderung auch ausdrücklich in die Developer Release Notes aufgenommen. bugzilla.mozilla.org
Außerdem ist das Ziel der Änderung grundsätzlich, Firefox' altes Sonderverhalten loszuwerden. Das initiale about:blank soll direkt vorhanden sein und nicht anschließend noch einmal durch einen asynchronen about:blank-Load ersetzt werden. Dass Mozilla im Zuge der Implementierung auch eigenen Code ändern musste, weil dieser auf dem alten Timing beruhte, spricht genau für diese Interpretation. bugzilla.mozilla.org
Meine technische Einordnung
Vor Firefox 148 konnte Joomla offenbar davon ausgehen, dass der installierte load-Handler erst einen späteren, relevanten Reload sieht. Firefox 148 hat durch das synchrone initiale about:blank diese Annahme verändert. Joomla musste daraufhin Initialisierungs-load und späteren Reload sauber voneinander unterscheiden.
Dass Chrome, Safari etc. vorher funktioniert haben, beweist hier nicht unbedingt einen Firefox-Bug. Gerade bei initialen about:blank-Dokumenten gab es historisch erhebliche Unterschiede zwischen Browsern; Bug 543435 ist ein 16 Jahre alter Firefox-Bug, dessen Behebung erst 2026 vollständig gelandet ist. bugzilla.mozilla.org
Kurz gesagt: Firefox 148 hat nicht einfach „TinyMCE kaputtgemacht“. Firefox 148 hat mit Bug 543435 das Lifecycle-/load-Verhalten initialer about:blank-iframes geändert. Joomlas eigener Reload-Mechanismus für TinyMCE konnte den dadurch auftretenden initialen load offenbar nicht von einem späteren iframe-Reload unterscheiden und löste deshalb seine eigene Reinitialisierungsschleife aus. PR #46889 macht diese Unterscheidung explizit. Das sieht für mich deutlich mehr nach einem notwendigen Joomla-Webcompat-Fix als nach einem Workaround für einen weiterhin bestehenden Firefox-Bug aus.
Die WHATWG-Diskussion zu genau diesem Problem beschreibt Chrome und Safari ausdrücklich so, dass die about:blank-Verarbeitung beim Einfügen synchron erfolgt, während Firefox sie damals noch asynchron ausführte. GitHub
Mozilla bezeichnet Bug 543435 deshalb selbst als Behebung eines „long-standing web compat issue“. Die Release-Note-Anfrage formuliert das Ziel als Herstellung eines „Web-compatible“ initial empty document: Die erste Navigation nach about:blank soll synchron abgeschlossen werden und das initiale Dokument nicht später durch ein zweites parser-generiertes Dokument ersetzt werden.
Das ist ein ziemlich deutlicher Hinweis darauf, in welche Richtung Mozilla die Sache selbst einordnet.
Warum war Joomla dann ausgerechnet in Chrome und Safari nicht kaputt?
Das ist der interessante Teil. Es reicht offenbar nicht, nur zu sagen:
Chrome/Safari sind synchron → Firefox 148 wird synchron → also müssten alle drei Joomla gleichermaßen kaputtmachen.
Denn das genaue Lifecycle-Verhalten von about:blank, initial empty documents und load ist historisch nicht vollständig interoperabel gewesen. Die WHATWG hat dazu über Jahre mehrere Issues gehabt; bereits 2016 wurde das Problem treffend mit „every browser disagrees“ beschrieben. GitHub
Besonders relevant ist das Timing des load-Listeners.
Nehmen wir vereinfacht so etwas:
JavaScriptconst iframe = document.createElement("iframe"); document.body.appendChild(iframe); // später: iframe.addEventListener("load", handler);Wenn Chrome/Safari ihr initiales load bereits synchron innerhalb von appendChild() auslösen, ist dieses Ereignis vorbei, bevor ein anschließend installierter Listener existiert.
Genau dieses Verhalten wurde in der WHATWG-Diskussion dokumentiert:
Chrome and Safari: The load event fires synchronously under the appendChild call
Firefox verhielt sich dagegen historisch anders: Dort startete die Einfügung eine asynchrone about:blank-Navigation. GitHub
Das führt zu einem wichtigen Unterschied:
CodeChrome/Safari: append iframe │ ├── initial about:blank ├── LOAD │ └── appendChild() kehrt zurück │ └── Joomla installiert Listener ↑ initiales load schon vorbeiDas Joomla-Handling sieht dieses initiale Ereignis also gar nicht.
Das alte Firefox-Modell konnte dagegen vereinfacht eher so aussehen:
CodeFirefox alt: append iframe │ ├── initial document │ └── appendChild() kehrt zurück │ ├── Listener wird installiert │ └── später: async about:blank │ └── LOAD ↑ Listener sieht esBug 543435 beseitigt genau diese merkwürdige zweite asynchrone Phase. bugzilla.mozilla.org
Und was macht die Spezifikation?
Hier wird es etwas komplizierter, weil die HTML-Spezifikation über die Jahre selbst geändert wurde, gerade um Realität und Interoperabilität zusammenzuführen.
Das heutige Modell kennt ein initiales about:blank Document, das unmittelbar beim Erzeugen des Browsing Context verfügbar ist. Für iframe gibt es außerdem ausdrücklich eine spezielle Behandlung des initialen load-Events; der Standard weist darauf hin, dass in diesem Initialisierungsfall ein synchrones load auftreten kann. html.spec.whatwg.org
Dass das initiale Dokument synchron existieren sollte, ist übrigens keine neue Idee. Schon die WHATWG-Diskussion von 2010 stellte fest, dass das damalige Standardmodell das Document beim Einfügen des iframe synchron erzeugt. Das damalige Gecko-Verhalten wich davon ab. lists.whatwg.org
Deshalb würde ich nicht sagen:
Firefox 148 verhält sich jetzt korrekter als Chrome und Safari.
Treffender wäre:
Firefox 148 hat eine alte Gecko-Eigenheit beseitigt und sein Verhalten grundsätzlich an das standardisierte und bereits von Chromium/WebKit verwendete synchrone Modell angenähert.
Bei den Details rund um load, History, initial-about:blank-Status usw. gibt es bzw. gab es trotzdem Unterschiede zwischen allen drei Engines. Beispielsweise zeigten Tests selbst bei der Frage, ob nach dem initialen leeren Dokument eine Navigation einen History-Eintrag ersetzt oder hinzufügt, erhebliche Unterschiede zwischen Chrome, Firefox und Safari. GitHub
Das macht den Joomla-Fix noch nachvollziehbarer
Und genau deshalb würde ich den Joomla-PR jetzt sogar noch eindeutiger als Robustheits-/Webcompat-Fix in Joomla einordnen.
Joomla sollte logisch nicht darauf angewiesen sein, wann genau der Browser das initiale load des TinyMCE-iframe auslöst. Joomla interessiert sich eigentlich für etwas anderes:
„TinyMCE war vollständig initialisiert und danach wurde sein iframe erneut geladen.“
Das ist semantisch etwas anderes als:
„Auf diesem iframe ist irgendein load aufgetreten.“
Der PR macht diese Unterscheidung expliziter. Erst wird die TinyMCE-Initialisierung abgewartet; danach werden zukünftige iframe-loads als Reload interpretiert.
Damit funktioniert Joomla unabhängig davon, ob Browser A das initiale about:blank synchron verarbeitet, Browser B dabei ein etwas anderes load-Timing hat oder Browser C intern sein initial empty document anders behandelt.
Kurzfassung: Firefox hat mit Bug 543435 sein lange abweichendes Modell an das synchrone Modell der anderen Engines und der Webplattform angenähert. Der Joomla-Bug entstand an einer subtilen Grenze dieses Lifecycle-Timings. Joomlas neuer Code verlässt sich weniger auf dieses Timing – und das ist aus Webentwickler-Sicht die robustere Lösung.
Hallo,
es handelt sich dabei offensichtlich um einen Bug in der Integration seitens Joomla, der bereits behoben ist, wie du selbst schon angedeutet hast. Das von dir verlinkte Thema zeigt auch auf die entsprechende Korrektur. WordPress beispielsweise nutzt ebenfalls TinyMCE im klassischen Editor und da gibt es auch keine Probleme in Firefox. Wieso kannst du deine Joomla-Version nicht aktualisieren? Hast du ansonsten wenigstens Zugriff auf das Dateisystem, um die Korrektur, die sich auf eine einzelne Joomla-Datei beschränkt, manuell zu übernehmen?
Abhilfe über Firefox für einen Bug, der nicht in Firefox liegt, erscheint mir schwierig.
Wenn unset anstatt none zum gleichen Ergebnis führt, ist es vollkommen in Ordnung, das zu nutzen. Beide Werte haben eine unterschiedliche Bedeutung und sind daher nicht pauschal austauschbar, aber können es je nach Fall sein. Wenn möglich, verzichte ich auch auf Hersteller-Präfixe (-moz-*), weil es mehr im Sinne des Standards und potenziell zukunftssicherer ist. Aber diese zu nutzen, wenn sie verfügbar sind, ist genauso richtig, wie darauf zu verzichten. Das hat keinen technischen Nachteil, wenn man sich ausschließlich im Kontext von Firefox bewegt, zumal es nur sehr selten vorkommt, dass die Unterstützung eines solchen Präfixes mal tatsächlich entfernt wird. Firefox versteht sogar -webkit-*-Präfixe, wenn man Lust darauf hat. Und das letzte Semikolon eines Blocks ist immer optional. Ich setze es auch immer, weil ich es mag, wenn der Code konsistent geschrieben ist. Und dann kann man auch die Reihenfolge verändern, ohne darauf achten zu müssen. Aber das ist kein Muss. CSS-Optimierer entfernen das letzte Semikolon in der Regel sogar, weil da der Gedanke ist, dass jedes Semikolon ein Bit ist, den man in der Datenübertragung sparen kann, und sich das mit vielen anderen Mikro-Optimierungen addiert. Diese drei Fälle würde ich also schon als grundsätzlich richtig bezeichnen, ohne damit zu sagen, dass ich es auch so schreiben würde.
In dem CSS von #19 sind einfach zu viele Fehler vorhanden!
Kleiner Auszug?
Teilweise sind das aber keine Fehler, die du bemängelst.
Nochmal: Es geht hier nicht um Firefox. Und auch nicht um ein einzelnes LLM, sondern um ein Gesamtsystem. Im Artikel habe ich beschrieben, worum es geht. Dort steht unter anderem auch, dass die Anwender dieses Systems selbst entscheiden können, welche Modelle sie einsetzen. Das kann auch ein Modell von Mistral sein. Alleine das sollte doch klar machen, dass es um unterschiedliche Dinge geht. Wieso du meinst, das würde aus politischen Gründen blockiert werden, oder die Frage, was du als Europäer davon hast, verstehe ich nicht. Wieso sollten Europäer denn nicht von einem offenen KI-System profitieren können? Wenn du wirklich meinst, als Europäer könnte man nur von Arbeit profitieren, die innerhalb Europas geschieht, halte ich das für eine sehr gewagte These …
ach echt?
Das lässt sich sogar ganz leicht bestätigen: Suche in der Store-Version nach dem Feature zum Ändern des App-Symbols. Das wirst du dort nicht finden.
übrigens: ich nutze die store-versionen seit Anbeginn ihrer Zeit und der Update-Prozess läuft hervorragend während des laufenden Betriebs. Es wird also aktualisiert unabhängig davon ob das Programm offen ist oder nicht (logischerweise wird es neu gestartet wie beim Play Store, was aber nicht dramatisch ist). bei der MSI/EXE version wird da update spätestens beim manuellen Neustart angestoßen
Für mich liest sich das so, als würde es in dem Aspekt einen relevanten Unterschied geben. Aber so oder so wird das Update im Hintergrund heruntergeladen und kann natürlich erst final installiert werden, wenn Firefox geschlossen ist. Die Konsequenz, wenn Firefox tatsächlich während der Verwendung aktualisiert würde, wäre, dass Firefox nicht wirklich benutzbar wäre, weil das Laden von Websites dann sofort fehlschlagen würde. Das ist der Grund, wieso Firefox eine entsprechende Fehlerseite anzeigt, wenn mehrere Instanzen einer Installation geöffnet sind und eine Instanz dann ein Update durchführt.
bspw. nach dem Schließen oder Beenden (kill) des Programms
Ein „kill” ist de facto ein Programmabsturz und bringt immer das Risiko von Datenverlusten. Das würde ich nicht mit einem ordnungsgemäßen Beenden gleichsetzen.
Es gibt Betriebe, da werden Update nicht installiert, weil die Rechner (Clienten( einfach nicht vernünftig neugestartet werden.
Ein Neustart des Rechners sollte normalerweise nie notwendig sein, um Anwendungen zu aktualieren.
Es gibt Unterschiede, aber nicht in dem Ausmaß, dass zu erwarten ist, dass eine Version Bluescreens auslöst und die andere Version nicht. Testen kann man es natürlich trotzdem.
Mila, nicht Mistral. Es geht dabei auch um kein Firefox-Feature und auch nicht allgemeiner um ein Endnutzer-Feature. Wie es im Artikel ausführlich beschrieben steht, geht es um Open Source KI-Lösungen für unter anderem Unternehmen, Krankenhäuser, gemeinnützige Organisationen und Behörden.
Sollte dieser Schalter wegfallen, was sicher kommen wird
Mit Firefox 161 soll die Option entfernt werden.
Ein neuer Artikel wurde veröffentlicht:
Artikel lesen: „Mozilla und Mila starten neue Open-Source KI-Initiative“
Meiner Meinung nach sind nach der Abkehr vom eigentlich geplanten Insel-Design die Änderungen wirklich moderat und betreffen vor allem Rundungen und Farben. Die größten Änderungen sehe ich da eher unter der Haube, weil da vieles unabhängig vom eigentlichen Design dafür optimiert worden ist, wie Firefox seine Design-Werte aus den Figma-Designs erhält. Das kann natürlich auch dafür sorgen, dass Adaptierungen deiner individuellen Anpassungen notwendig sein werden. Aber alles, was bisher machbar war, wird definitiv weiterhin machbar sein. Und wenn Hilfe benötigt wird, steht dieses Forum zur Verfügung.
