Gibt es Abhilfe über den Firefox?
Ist das nur mit dem Firefox so, oder auch mit einem anderen Browser?
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.
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.
