Beiträge von Sören Hentzschel

Nutzt für politische Diskussionen bitte andere Plattformen als diese hier. Siehe auch Punkt 2.2 der Forenregeln.

Wenn ich die angegebene Seite speichere und dann in der lokalen Version die Links auf der linken Seite anklicke, kann ich keinen Unterschied zu Firefox 128 oder auch Firefox 115 erkennen. Dass sich das Verhalten von der Online-Version unterscheidet, schon. Aber wenn du dir sicher bist, dass das Problem erst seit Firefox 134 besteht, dann lässt sich das Problem nicht durch Speicherung der Online-Version über Firefox reproduzieren. In dem Fall wäre es gut, wenn du deine lokale Version als ZIP packen und hier anhängen könntest. Ich kann nicht ausschließen, dass durch die Speicherung seitens Firefox Dinge verändert werden.

Hallo,

ich habe deine Frage in ein eigenes Thema verschoben.

Um etwas zu einem Problem auf einer bestimmten Seite sagen zu können, musst du diese bitte mit uns teilen.

Hallo,

für ein schnelles Wechseln kannst du diese Erweiterung nutzen:

Language Switch – Holen Sie sich diese Erweiterung für 🦊 Firefox (de)

Laden Sie Language Switch für Firefox herunter. Erlaubt das Ändern der Sprachkennung, die an Webserver gesendet wird, auf jeden beliebigen Wert.

addons.mozilla.org

Zitat von kleinesEulchen

Der Fehler lag nicht bei Avast sondern bei Firefox

Du meinst, an einer deiner Einstellungen? Denn ein weiteres Firefox-Update gab es keines und von alleine lösen sich Probleme nicht. Demnach muss sich entweder eine deiner Einstellungen geändert haben oder die Erweiterung wurde in der Zwischenzeit aktualisiert. Standardmäßig geschieht dies automatisch, ohne dass man das als Benutzer mitbekommt.

Zitat von Speravir

Heißt das, wenn onClick genutzt wird, dass der Eventlistener click lauten muss?

Das heißt es grundsätzlich. Die Attribute für Inline-Eventlistener beginnen immer mit on und das lässt man dann weg, weil das nicht Teil des Event-Namens ist. Und mit grundsätzlich meine ich, dass dem so ist, wenn wir hier wirklich vom entsprechenden HTML- / XUL-Event sprechen. Man darf nicht blind alles ersetzen, was mit on beginnt. Die onClick- oder onBuild-Methoden, die Teil der CustomizableUI.createWidget-API sind, bleiben beispielsweise so.

Ein neuer Artikel wurde veröffentlicht:

Zitat

Firefox Klar ist ein spezialisierter Privatsphäre-Browser. Nun hat Mozilla Firefox Klar 134 für Android veröffentlicht.

Artikel lesen: „Mozilla veröffentlicht Firefox Klar 134 für Android“

Die Ursache muss dann aber bei einem Script liegen. Denn die genannte Option hat mit CSS nichts zu tun, sonder nur mit JavaScript. Es kann natürlich sein, dass ein Script auch die Darstellung beeinflusst und das CSS mit Script etwas anders aussehen muss als ohne.

Zitat von ^L^

PS: Ja ich nutze idente (ausser dem Namen) Stamm-Profile für derzeit 4 unterschiedliche Firefox Versionen.

Dann hast du deine Erklärung. So etwas muss fast irgendwann zu Datenverlusten (wenn auch nur aus Sicht der neueren Versionen) führen. Nicht grundlos nutzt Firefox standardmäßig ein Profil pro Installation und verhindert, dass ein Profil mit einer älteren Version gestartet wird. Zwischen unterschiedlichen Firefox-Versionen zu wechseln wird aus gutem Grund nicht unterstützt. Nutze stattdessen die Synchronisation. Die ist genau dafür da.

In der Zukunft wird das so nicht mehr funktionieren und die Scripts müssen umgeschrieben werden. Es geht konkret um die Inline-Eventhandler, also sowas wie oncommand. Wir hatten das Thema vor ein paar Monaten schon, als Mozilla da angefangen hatte, das für eigenen Code umzustellen. Und das wird zukünftig via Content Security Policy (CSP) unterbunden und funktioniert damit auch in euren Scripts nicht mehr.

Nur mal am Beispiel des ersten Scripts.

Alt:

CustomizableUI.createWidget({
  /* … */
  onBuild: function(aDocument) {
    var toolbaritem = aDocument.createXULElement('toolbarbutton');
    var props = {
      /* … */
      style: '…',
      oncommand: "Services.dirsvc.get('UChrm', Ci.nsIFile).launch();"
    };
    for (var p in props)
      toolbaritem.setAttribute(p, props[p]);
    return toolbaritem;
  }
});

Neu:

CustomizableUI.createWidget({
  /* … */
  onBuild: function(aDocument) {
    var toolbaritem = aDocument.createXULElement('toolbarbutton');
    var props = {
      /* … */
      style: '…'
    };
    for (var p in props)
      toolbaritem.setAttribute(p, props[p]);
    
    toolbaritem.addEventListener('command', () => {
      Services.dirsvc.get('UChrm', Ci.nsIFile).launch();
    });
    
    return toolbaritem;
  }
});

Ich habe hier bewusst Stellen weggelassen (durch „…“ gekennzeichnet), damit die Änderungen übersichtlich bleiben. Kurz: oncommand entfernen und durch addEventListener ersetzen. Im Detail wird das hoffentlich durch den Code klar.

Hallo,

vorerst kannst du security.browser_xhtml_csp.enabled in about:config auf false setzen.

Hallo,

wie genau hast du das Update durchgeführt? Denn, wenn über Firefox selbst, dann wärst du jetzt bei Firefox 134 und nicht bei Firefox 133. Und welche Version war vorher installiert? Etwa Firefox 125, weil du explizit diese Version nennst?

Was meinst du außerdem mit „Ich verwende immer das selbe Profil“? Dass sich das durch Updates nicht verändert, ist klar. Aber nutzt du mehrere Installationen mit dem gleichen Profil? Das wäre fatal und würde leicht genau solche Probleme erklären.

Das mit dem Updaten von Apps über den Play Store, die aus einer anderen Quelle installiert worden sind, scheint ein ziemlich neues Feature zu sein. Das erfordert dann aber auch ein explizites Opt-in vom Benutzer. Ich habe es selbst noch nicht getestet und weiß auch nicht, ob das schon für alle Nutzer ausgerollt ist.

Ich bemerke auf wetteronline.de mit Firefox 133.0.3 auf Android keine Probleme. Aber wenn das mit Firefox 134 für dich passt, muss man das ja nicht weiter verfolgen. Ich würde dann nur beim nächsten Update zur Sicherheit nochmal schauen, ob das mit der Aktualisierung tatsächlich funktioniert.

Ausrollungen über den Google Play Store erfolgen immer schrittweise. Manchmal ist man früher dran, manchmal später. Das lässt sich als Nutzer auch nicht beeinflussen.

Grundsätzlich handelt es sich um diese Version, ja. Aber ich will jetzt nicht „identisch“ sagen, weil für Nutzer mit anderer Architektur unter Umständen ein anderer Build der richtige ist. Außerdem gibt es keine Updates, wenn man sich Firefox auf diese Weise installiert.

Hallo,

da es sich offensichtlich um lokale Dateien auf deinem Computer handelt, lässt sich für andere schlecht etwas dazu sagen, wo das Problem liegt. Kannst du vielleicht eine entsprechende Seite mit Link so vorbereiten, dass du sie mit uns teilen kannst?

Ein neuer Artikel wurde veröffentlicht:

Zitat

Mozilla hat Firefox 134 für Android veröffentlicht. Dieser Artikel beschreibt die Neuerungen von Firefox 134 für Android.

Artikel lesen: „Mozilla veröffentlicht Firefox 134 für Android“

Das hat nicht wirklich eine Aussagekraft. Die IP-Adresse kann auf 20 solcher Listen stehen, wenn das Sicherheitssystem diese Listen nicht nutzt. Umgekehrt muss die IP-Adresse auf keiner einzigen öffentlichen Liste stehen und kann am Ende trotzdem ausgerechnet auf einer Liste dieses Anbieters stehen. Die IP-Adresse (zumindest alleine) scheint außerdem auch nicht das Problem zu sein, siehe Beitrag #9. Dass der Thementitel nicht stimmt, darauf habe ich bereits in Beitrag #7 hingewiesen.

Es muss auch gar nicht sein, dass am Firefox des Themenstarters irgendetwas nicht stimmt. Die Sache mit solchen Sicherheitssystemen ist, dass sie verschiedene Faktoren einbeziehen und daraus eine Wahrscheinlichkeit dafür berechnen, wie vertrauenswürdig ein Besucher ist oder auch nicht ist. Aber was genau diese Kriterien sind, weiß niemand von uns. So etwas wird nicht öffentlich kommuniziert, denn die Entwickler solcher Systeme wollen natürlich nicht, dass man das System austricksen kann.

Insofern können wir hier natürlich Vermutungen anstellen und Dinge nennen, die man ausprobieren könnte. Aber belastbare Schlussfolgerungen können wir nicht treffen, wenn ein solches System im Einsatz ist. Das könnte höchstens der Betreiber der Website, wenn ihm die „Incident ID“ mitgeteilt wird.

Das ist durch die nachfolgenden Beiträge doch schon geklärt.

Zitat von 2002Andreas

Ansonsten:

Zitat von Sören Hentzschel

aber nicht über das file:-Protokoll.

Und so ist es hier auch.

Du hattest das Bild laut Fehlermeldung in der Konsole via file:// eingebunden. Das ist etwas anderes als ein relativer Pfad. Ein relativer Pfad beinhaltet kein Protokoll. Und das funktioniert dann auch.

Zitat von 2002Andreas

Ich weiß nicht warum, aber Bilder lassen sich nur per base64 Code einfügen

Das geht grundsätzlich schon, aber nicht über das file:-Protokoll. Das liegt an der Content Security Policy (CSP), die genau das verbietet, siehe Fehlermeldung, die dein Screenshot zeigt. Du kannst Folgendes im Quelltext der Startseite finden:

<meta
      http-equiv="Content-Security-Policy"
      content="default-src 'none'; object-src 'none'; script-src resource: chrome:; connect-src https:; img-src https: data: blob: chrome:; style-src 'unsafe-inline';"
    />

Dort taucht file: nicht für die img-src-Direktive auf.