Beiträge von Sören Hentzschel

Zitat von geldhuegel

ich habe aufgrund deines Berichts das mal ausprobiert. Leider weiß ich jedoch nicht, wie ich die Farbauswahl Pop-ups in deinen Bildern 3-5 hervorholen kann.

Bitte gib mir mal einen kleinen Hinweis.

• about:addons → Themes oder
• Startseite → Anpassen (in der Ecke rechts unten)

Voraussetzung: Nova ist aktiviert. Das ist standardmäßig ab Firefox 157 der Fall.

Zitat von Mira_Belle

Nur auswählen kann ich da noch nichts.
Version 156.0.1

Was geht, hell oder dunkel.

Mal abgesehen davon, dass das auch in Firefox 156.0.1 funktioniert, wird Nova erst ab Firefox 157 offiziell unterstützt. Alle Tests in vorherigen Versionen sind relativ sinnlos.

Hinweis dazu: Je nach Internetverbindung kann die Auswahl eines Themes, das vorher noch nicht genutzt worden ist, einen kurzen Moment dauern, weil das ausgewählte Theme beim ersten Mal erst von addons.mozilla.org heruntergeladen wird.

Ein neuer Artikel wurde veröffentlicht:

Zitat

Am Dienstag wird Mozilla Firefox 157 veröffentlichen und damit hält auch das neue Nova-Design in Firefox Einzug. Dieser Artikel gibt eine Vorschau auf das neue Firefox-Design, neue Funktionen und Nutzer-Optionen, die damit einhergehen, und geht auch auf Unterschiede im Vergleich zu den ersten Mockups ein.

Artikel lesen: „Große Vorschau auf das neue Nova-Design von Firefox 157“

Ich bezweifle, dass es viele Nutzer gibt, die sich dafür interessieren, welche Stelle der Versionsnummer sich ändert (Minor wäre im Übrigen die zweite Stelle und die ändert sich nur bei ESR-Updates). Es geht wie gesagt darum, dass Mozilla Neuerungen schneller an die Nutzer bringen möchte. Was Google macht, mag dir egal sein, ist aber für Mozilla eine relevante Abwägung, weil Google einen Wettbewerbsvorteil hätte, wenn sie doppelt so häufig Neuerungen ausliefern. Und Google ist eben mit Abstand der Marktführer, an dem man sich orientiert.

Man kann so etwas auch leicht übersehen, vor allem, wenn man nicht bewusst darauf achtet. Und dass das einen Unterschied für die Firefox-Oberfläche macht, ist auch nicht unbedingt etwas, was jedem bekannt ist.

Ein neuer Artikel wurde veröffentlicht:

Zitat

Von Thundermail, dem E-Mail-Dienst der Thunderbird-Macher, gibt es auch eine Weboberfläche. Diese hat zahlreiche Neuerungen erhalten.

Artikel lesen: „Webmail-Version von Thundermail erhält zahlreiche Neuerungen“

Das hat nichts mit Nightly und Beta zu tun. Die Standard-Reihenfolge wurde bewusst geändert und wird auch in der finalen Version so aussehen. Dass sich Firefox eine geänderte Reihenfolge merkt, hat noch nie funktioniert. Das entsprechende Bugzilla-Ticket wurde bereits vor zwei Jahren erstellt (und vor weniger als zwei Wochen einer Entwicklerin zugewiesen):

Nein, das hat nichts damit zu tun, wie Bugfix-Updates angekommen sind. De facto macht das vom Update-Prozess her ja überhaupt keinen Unterschied für die Nutzer. Der Grund steht in meinem vorherigen Beitrag in der Zitat-Box.

Firefox kann sich eine veränderte Reihenfolge aktuell nicht merken. Das ist aber für die Zukunft geplant.

Zitat von Mozilla

Ziel ist es, veröffentlichungsreifer Arbeit häufiger die Möglichkeit zu geben, die Nutzer zu erreichen. Gleichzeitig soll der Veröffentlichungsprozess planbarer werden und der Druck sinken, Änderungen nachträglich in einen Release aufzunehmen.

Chrome hat den Zyklus außerdem ebenfalls auf zwei Wochen verkürzt.

Ich habe das Spiel nicht gesehen. Aber sowohl Deutschland als auch Niederlande hatten einen neuen Trainer und kaum Zeit, irgendetwas mit der Mannschaft zu machen. Große Rückschlüsse sollte man aus dem Spiel also so oder so nicht ziehen. Nur ausgehend von den reinen Statistiken dürfte das Remis für Deutschland schmeichelhaft gewesen sein.

Zitat von .DeJaVu

Das ist keine Ursache, das ist funktional folgend. Ein maximiertes Fenster kann man nicht verschieben

Richtig, ein maximiertes Fenster kann nicht verschoben werden. Und genau deswegen ist es die Ursache für die Beobachtung des Themenstarters.

Zitat von .DeJaVu

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.

Zitat von djkroko

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.

Zitat von rudi999

Danke, verstehe ich aber eigentlich nicht, warum...

Siehe Beitrag #4. Du wünschst dir etwas, was so gar keinen Sinn ergibt … Könntest du einfach die E-Mail-Adresse ändern, ohne nachgewiesen zu haben, dass du Zugriff auf die E-Mail-Adresse hast, könnte man sich den kompletten Schutz auch sparen, weil eine unbefugte Person dann nur deine E-Mail-Adresse ändern müsste, um den Verifizierungs-Schritt komplett zu umgehen. Und das würde die ganze Maßnahme nutzlos machen.

Eine E-Mail-Adresse ist ein eindeutiges Identifizierungsmerkmal. Den Zugriff darauf zu verlieren, hat fast überall Konsequenzen.

Das ist ja bei den meisten Problemen so, dass sie nur manche Nutzer haben. Der Tracking-Schutz verhindert jedenfalls keinen direkten Aufruf von Google und auch von sonst keiner Website. Das ist nicht die Funktionsweise. Und die Fehlermeldung des Themenstarters ist wie gesagt eindeutig dahingehend, dass die Einbettung von einer anderen Domain abgelehnt wird, und der Tracking-Schutz entscheidet nicht, was GMX von wo einbettet. Gerade bei einem so großen Dienst ist es leicht vorstellbar, dass vielleicht ein CDN genutzt wird, welches über verschiedene Domains läuft, und eine Domain nicht korrekt konfiguriert ist, was dann erklären würde, wieso es nur für manche Nutzer und auch für die nur teilweise auftritt. Dieser Fehler deutet eigentlich immer auf ein Website-Problem hin, weil man als Nutzer gar keinen Einfluss darauf hat.

Hallo,

es würden den gesamten Schutz ja auch ad absurdum führen, wenn man keinen Zugriff auf das Mail-Konto bräuchte, um das Mail-Konto zu ändern.

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?

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.

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:

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?

Die Meldung besagt, dass ein Inhalt von einer anderen Domain eingebettet wird, die das nicht erlaubt. Das ist nichts, worauf der Tracking-Schutz irgendeinen Einfluss hätte.

Was sagt denn der Support von GMX dazu? Dieses Problem muss grundsätzlich in jedem Browser bestehen, da sich ausnahmslos alle Browser an die Restriktionen halten, welche diese Meldung auslösen.