Tabs crashen seit 156

  • Firefox-Version
    156
    Betriebssystem
    Win 11

    Hallo zusammen,


    ich habe seit FF 156 auch 156.0.1 das Problem das bei mir laufend ein Tab crasht.

    Mit dem Tab bin auf einem Ticketsystem von znuny.

    Wenn das Tab crasht und ich auf wiederherstellen klicke, crasht der Tab direkt wieder.


    Firefox habe ich schon einige Male neu installiert und auch ein neues Profil getestet, ohne Erfolg.

    Mache ich ein Downgrade auf 155.0.1 funktioniert die Seite Problemlos.


    Absturzmeldungen in about:crashes gibt es nicht.


    Ein Kollege, der auch mit Firefox auf das Ticketsystem zugreift hat keine Probleme.


    Habt ihr noch eine Idee, wie ich dem Problem auf die Schliche kommen könnte?


    Danke

    Gruß

    djkroko

  • Hallo,

    Absturzmeldungen in about:crashes gibt es nicht.

    Abstürze sollten geloggt werden. Hast du das Melden von Abstürzen deaktiviert? Absturzmeldungen wären schon wichtig, um die Ursache zu finden.

    Ansonsten wäre es gut, wenn du mozregression ausführen könntest:

    mozregression

    Als letzte bekannte gute Version wählst du Firefox 155 (Achtung: Standardmäßig ist „date” ausgewählt, das musst du vorher auf „release” umstellen, danach kannst du die Version wählen), als erste bekannte schlechte Version wählst du Firefox 156. Dann wird Build für Build gestartet, die du alle testest und anschließend „Good” oder „Bad” wählst, je nachdem, ob das Problem auftritt oder nicht. Das machst du so lange weiter, bis kein Build mehr geladen wird, und am Ende teilst du die letzte Pushlog-URL mit uns.

  • Abstürze sollten geloggt werden.

    Ich würde das gerne betonen. Ohne spezielle Eingriffe merkt sich Firefox sowas. Ich hoffe, du bist kein "Opfa" bestimmter Seiten geworden, die das und ähnliches mit einer user.js abwürgen, weil jene Seiten extrem "dumm".

    Ich kann mich zwar nicht anmelden, aber der Aufruf jener dieser welcher Seite blieb hier folgenlos, trotz Werbeblocker etc.

    Für dich evtl befremdlich, aber für uns sehr hilfreich:


    Bitte benötigte Informationen abgeben
    Detaillierte Informationen zur Fehlerbehebung erhalten, um Probleme mit Firefox zu lösen
    ● Hamburger-Button ☰ ➜ (?) Hilfe ➜ Informationen zur Fehlerbehebung
    ● Die Schaltfläche "Text in die Zwischenablage kopieren" anklicken
    ● Den kopierten Text aus der Zwischenablage als Code (siehe Bild]hier ins Forum einfügen.

    Frei nach Einstein: „Zwei Dinge sind unendlich, Marketing und die menschliche Gutgläubigkeit, bei einem bin ich mir noch nicht ganz sicher.“

    Meine Glückszahl hier: 98.

  • Also mittlerweile habe ich es hinbekommen, das ich wieder crash Reports habe.

    Aktuell schlägt aber das senden der Logs fehl.


    Die Anleitung:

    Bitte benötigte Informationen abgeben
    Detaillierte Informationen zur Fehlerbehebung erhalten, um Probleme mit Firefox zu lösen
    ● Hamburger-Button ☰ ➜ (?) Hilfe ➜ Informationen zur Fehlerbehebung
    ● Die Schaltfläche "Text in die Zwischenablage kopieren" anklicken
    ● Den kopierten Text aus der Zwischenablage als Code (siehe Bild]hier ins Forum einfügen.


    Scheint so nicht mehr zu stimmen. Nach Hilfe gibt es kein "Informationen zur Fehlerbehebung"


    Mozregression habe ich versucht, leider gibts ein Fehler beim Start, wahrscheinlich auf grund einer Einstellung in der Firewall

  • Aktuell schlägt aber das senden der Logs fehl.

    Wie äußert sich das? Erhältst du einen Fehler?

    Nach Hilfe gibt es kein "Informationen zur Fehlerbehebung"

    Der Menüpunkt heißt „Weitere Informationen zur Fehlerbehebung” …

    Mozregression habe ich versucht, leider gibts ein Fehler beim Start, wahrscheinlich auf grund einer Einstellung in der Firewall

    Auch hier: Was ist der Fehler? Wenn eine simple Anwendung nicht starten kann, scheinen mir die Probleme auf deinem System größer zu sein und über Firefox hinaus zu gehen …

  • Beim Log senden kommt einfach Fehlgeschlagen, wenn ich im about:crashes auf Senden klicke.


    Mozregression funktioniert aufgrund von aktiver https inspection nicht. Mittlerweile habe ich es testweise deaktivert, aber bei manchen Builds blockt nun der Defender.


    Infos von "Weitere Informationen zur Fehlerbehebung"


    Einmal editiert, zuletzt von djkroko (25. September 2026 um 09:11)

  • Du hast die Datei user.js in deinem Profilverzeichnis. Stelle mal deren Inhalt hier ein.

    Übersetzer für Obersorbisch und Niedersorbisch auf pontoon.mozilla.org u.a. für Firefox, Firefox für Android, Firefox für iOS, Firefox Klar/Focus für iOS und Android, Thunderbird, Pootle, Django, LibreOffice, LibreOffice Onlinehilfe, WordPress

  • funktioniert aufgrund von aktiver https inspection nicht. Mittlerweile habe ich es testweise deaktivert

    Das sollte nicht nur testweise, sondern dauerhaft deaktiviert bleiben! Dieses Feature ist ein sogenannter Man-in-the-Middle (MITM), wie es Schadsoftware nicht anders macht, und reduziert deine Sicherheit! Wenn es um HTTPS-Sicherheit geht, bieten Browser von Haus aus das höchste Sicherheits-Niveau. Darüber hinaus hat diese Art von Feature in der Vergangenheit schon zahlreiche Firefox-Probleme verursacht.

    Hast du von mozregression auch eine sogenannte Pushlog-URL erhalten? Davon wäre die letzte relevant.

  • Inhalt aus der user.js

    Code
    user_pref("security.enterprise_roots.enabled",true/*REQUIRED_BY_DYMO*/);


    Bei mozregression wurden URLs angezeigt ja, inzwischen hatte ich das Programm aber schon zu.

    Ich schau das ich es nochmal mache.

  • Das ist schon länger auf true by default, warum also noch? Und warum nicht per Policy?

    Unternehmensrichtlinien: Aktiv

    Und wo ich schon dabeibin, was zeigt denn about:policies?

    Und mir ist noch was aufgefallen:

    network.generic-ntlm-auth.workstation

    Das ist nicht zufällig ein Arbeitsrechner?

    Frei nach Einstein: „Zwei Dinge sind unendlich, Marketing und die menschliche Gutgläubigkeit, bei einem bin ich mir noch nicht ganz sicher.“

    Meine Glückszahl hier: 98.

  • Danke. Der Pushlog beinhaltet zwei Bugs und der eine kann es nicht sein, weil der nur Android betrifft. Damit bleibt folgende Korrektur als Auslöser übrig:

    2066182 - Crash in [@ mozilla::dom::ViewTransition::MatchClassList]
    RESOLVED (emilio) in Core - CSS Parsing and Computation. Last updated 2026-09-03.
    bugzilla.mozilla.org

    Grundsätzlich ist es natürlich nicht auszuschließen, dass eine Korrektur unerwünschte Nebenwirkungen hat. Ist das denn ein öffentliches System, auf dem sich jeder registrieren und versuchen kann, das Problem zu reproduzieren?

  • Nein, das system ist nur intern zugänglich.


    Was bei dem Problem interssant finde, das dies scheinbar nur an meinem System auftritt, andere Kollege mit der neuen Firefox Version haben diesen Fehler nicht.


    Wenn ich den Bug Verlauf so ansehe, scheint es aber so, das der Bug in 156 schon gefixt ist oder nicht?

  • Wenn dieser Bug das Ergebnis deines mozregression-Durchlaufs war und wir davon ausgehen, dass du das Problem zuverlässig reproduzieren kannst, bei einem weiteren mozregression-Durchlauf also nicht plötzlich ein anderes Ticket herauskommen würde, dann bedeutet das, dass die Änderung, die im Rahmen dieses Tickets durchgeführt worden ist, der Auslöser für dein Problem ist. Demnach wäre bei der Lösung eines anderen Problems dein Problem entstanden.

    Man könnte das Problem nun Mozilla melden und das wäre auch eigentlich sehr sinnvoll, wenn Firefox nicht dauerhaft davon betroffen sein soll. Wenn das Problem aber nur auf dieser Seite auftritt und von anderen nicht geprüft werden kann, macht es das Problem auch für Mozilla schwer bis unmöglich zu beheben. In dem Fall wäre ein Absturzbericht wirklich das Mindeste, um Mozilla irgendetwas zu geben, womit sie arbeiten können.

  • GIbts den einen manuellen Weg die Crash Reports an Mozilla zu senden?


    Wie ich bereits erwähnt hatte, kommt im about:crashes Tab, sofort Fehlgeschlagen, sobald ich einen oder alle Reports senden will.

  • Jedenfalls keinen einfachen. Theoretisch könnte das über das Senden bestimmter Dateien via cURL an die Schnittstelle von Mozillas Absturzsystem funktionieren. Aber das ist ein Weg, den ich selbst noch nie getestet habe und vielleicht auch gar nicht funktioniert.

    Kannst du denn einen neuen Absturz erzeugen und dann direkt ein paar Minuten danach unter about:crashes schauen, ob das dann mit dem Senden vom neuesten Absturzbericht funktioniert?

  • Habe ich gerade getestet, es kommt wieder sofort fehlgeschlagen.

    Ich habe gerade auch nochmal mozregression laufen lassen, diesmal aber nur auf den release channel eingestellt, beim letzten lauf, hatte er alle nightly Bulids durchprobiert.

    Das Pushlog sieht diesmal anders aus:

    mozilla-release pushlog feed
    Rendered pushlog feed for mozilla-release
    hg.mozilla.org


    Code
    2026-09-25T11:01:47.735000: DEBUG : Found commit message:
    No Bug - Update configs after merge day operations a=release
    
    IGNORE BROKEN CHANGESETS
    CLOSED TREE
    
    
    2026-09-25T11:01:47.737000: DEBUG : Did not find a branch, checking all integration branches
    2026-09-25T11:01:47.741000: INFO : The bisection is done.
    2026-09-25T11:01:47.744000: INFO : Stopped
  • Das Pushlog sieht diesmal anders aus:

    Der Pushlog beinhaltet einfach eine längere Spanne, sprich wurde ab einem gewissen Punkt nicht weiter eingrenzt (wieso auch immer). Das vorhin genannte Bugzilla-Ticket befindet sich aber auch noch innerhalb dieser Spanne.

    Was mir noch als Möglichkeit einfallen würde: Nicht gesendete Absturzberichte befinden sich lokal auf deinem Computer. Leider in einem Format, das nicht so einfach lesbar ist, und ein direkter Upload auf Mozillas Plattform außerhalb von about:crashes ist nicht so einfach möglich. Aber theoretisch könnte man einen Bug-Report erstellen und die Dateien dort anhängen. In der Hoffnung, dass Mozilla in der besten Position ist, um daraus einen brauchbaren Bericht zu erstellen. Wäre es eine Option für dich, wenn ich dir sage, wo du die Dateien findest, ein Bugzilla-Ticket zu erstellen, und dort die Dateien anzuhängen? Oder alternativ mir die Dateien zu schicken, damit ich es anlege, falls du dir das nicht zutraust? Ich sage gleich dazu, dass ich nicht weiß, welche ggf. privaten Informationen in den Dateien stecken, da ich selbst nicht einmal weiß, wie man diese lesen kann. Das macht normalerweise Mozillas Online-Plattform automatisch. Aber ich sehe keinen anderen Weg, als irgendwie damit zu arbeiten, um zu einer Lösung zu kommen. Und ich weiß leider auch nicht, wo man ansetzen muss, damit das Senden via about:crashes funktioniert, weil das eigentlich funktionieren müsste.

  • Was mich wundert, dass jenes Ticket schon vor einem Monat als "fixed" markiert wurde, so alt ist v156 noch gar nicht als Final. Und v156.0.1 ist auch schon raus.

    Man müsste das Ganze schon mal ohne Intranet etc ausprobieren, anderer Rechner, neues Profil ohne aufgezeigte Eingriffe.

    Und da wie angemerkt das ein Arbeitsrechner mit Anbindung an ein Intranet ist, könnte in dem Zusammenhang alles Mögliche zutreffen, was wir nicht sehen. Und dann müsste auch der zuständige Admin mit ins Boot genommen werden.

    Frei nach Einstein: „Zwei Dinge sind unendlich, Marketing und die menschliche Gutgläubigkeit, bei einem bin ich mir noch nicht ganz sicher.“

    Meine Glückszahl hier: 98.

  • Was mich wundert, dass jenes Ticket schon vor einem Monat als "fixed" markiert wurde, so alt ist v156 noch gar nicht als Final. Und v156.0.1 ist auch schon raus.

    Patches landen immer zuerst in Nightly-Versionen. Darauf bezieht sich auch immer der Status auf Bugzilla. Für Patch-Updates gibt es keinen eigenen Status, wäre in dem Fall aber auch irrelevant, da der Regressor ja bereits in Firefox 156.0 gelandet ist und demnach natürlich auch in Firefox 156.0.1 vorhanden ist, wenn es keinen Bugfix geschweige denn überhaupt einen Bug-Report bis hinerhin gibt.