Beiträge von Sören Hentzschel

Hallo,

Anpassungen in der Datei userChrome.css haben nichts mit der Website-Darstellung zu tun.

Für mich sieht das eher nach einer Kombination von nicht sehr breitem Bildschirm und Zoom aus. Denn die Schrift sieht für mich größer aus, als sie normalerweise angezeigt wird. Firefox zeigt zwar eine Zoom-Stufe von 100 Prozent an, aber es spielen auch noch andere Faktoren mit hinein, wie die Skalierungs-Einstellungen von Windows oder layout.css.devPixelsPerPx in about:config. Ich sehe bei mir auch keinen Unterschied im Vergleich mit älteren Firefox-Versionen oder Chrome.

PS: Bitte benenne immer einen Link, im ersten Fall wäre das https://www.acer.com/at-de/support/…G.001/downloads. Das von Hand ablesen und eintippen zu müssen, ist unnötig mühsam.

Schema F:

menuitem.setAttribute("oncommand", "navigator.clipboard.writeText(gContextMenu.linkTextStr);");

=>

menuitem.addEventListener('command', () => {
  navigator.clipboard.writeText(gContextMenu.linkTextStr)
});

Den Fehler hast du behoben, aber grisu2099 fragte nach der Prüfung, ob es bereits eine existierende Datei gibt, was du bemängelt hattest. Wenn ich mir den Code-Unterschied anzeige, wurde in diese Richtung nichts geändert.

Zwei Verbesserungsvorschläge, wo ich sie gerade sehe:

1. Cu.import('resource://gre/modules/Services.jsm'); gehört entfernt. Das war vorher auskommentiert, in der neuen Version wird das wieder ausgeführt. Die Datei gibt es nicht, entsprechend löst diese Zeile einen Fehler aus, wenn sie ausgeführt wird. In dem Fall kommt es doch nicht dazu, da vorher geprüft wird, ob Services definiert ist, und das ist immer der Fall. Aber dann kann man es auch gleich weglassen.

2. Ich sehe hier immer wieder (nicht nur in diesem Script) Vergleiche mit ==. Nach Möglichkeit sollte immer === verwendet werden. Das ist der striktere Vergleich und kann damit Fehler vermeiden, die entstehen können, wenn eine Seite des Vergleichs einen unerwarteten Typ hat. Außerdem ist === schneller. Es gibt nur Ausnahmesituationen, in denen == gebraucht wird.

Zitat von Speravir

Die Fehler, die Sören sah, erhalte ich nicht (ich hab das Skript direkt von Alice bezogen und die Texte übersetzt bzw. aus der Vorgängerversion übernommen).

Dann ist das ja logisch. Ich hatte mich auf das Script in der Version bezogen, die hier im Forum geteilt wurde. Ich schrieb ja sogar, dass das Originalscript den einen Fehler nicht hat. Zum anderen Fehler schrieb ich nichts, aber der ist dort ebenso nicht vorhanden.

Du hast ja schon geschrieben, dass deine Authenticator-App Firefox nicht kennt, daher wird das nicht klappen.

Zitat von 2002Andreas

Nein, dieser Eintrag ist gemeint:

Das ist aber erstens kein Tooltip und zweitens zeigt der Screenshot von lenny2 in Beitrag #314 einen Tooltip. Daher gehe ich mal davon aus, dass das gemeint ist.

Hallo,

wenn dein Google Authenticator Firefox nicht kennt, gibt es wahrscheinlich auch einen Zusammenhang zu den nicht funktionierenden Wiederherstellungscodes. Da scheint etwas mit deiner Zwei-Faktor-Authentifizierung nicht zu passen. Das ist aber kein Firefox-Problem und hätte vor dir überprüft werden müssen, bevor du dich darauf verlässt.

Auch solltest du wichtige Daten regelmäßig sichern. Die Verwendung der Synchronisation schützt logischerweise nicht vor Datenverlusten, die in Zusammenhang mit dem Mozilla-Konto selbst stehen.

Ich weiß, dass dir das nicht hilft, aber ohne Zugriff auf dein Mozilla-Konto kommst du auch nicht an die Daten, die in deinem Konto gespeichert sind. Nicht einmal Mozilla selbst hätte Zugriff darauf, weil deine Daten durch deinen persönlichen Login individuell verschlüsselt sind. Ein Zurücksetzen des Zugangs führt aus diesem Grund auch zu einer vollständigen Löschung aller Daten auf dem Mozilla-Server.

Zumindest bietet so ziemlich jede Website, auf der man einen Account hat, eine Funktion zum Zurücksetzen des Passworts an. Ein anderer Weg fällt mir auch nicht ein.

Zitat von lenny2

Ich werde die Variante von mulipo aus Beitrag #180 (#304) verwenden, die ohne Löschen der Tab-Liste funktioniert.

Die Version hat aber auch mehrere Fehler, siehe #306 für die notwendigen Korrekturen.

Aus Firefox-Sicht ist deine Nvidia-Grafikkarte nicht aktiv, nur der Onboard-Chip. Deswegen hast du keine Hardwarebeschleunigung. Ansonsten könnte ich mir schon vorstellen, dass WebGL2 funktionieren würde.

Wie sieht es denn nach Setzen von layers.acceleration.force-enabled auf true und anschließendem Neustart von Firefox aus?

Die Option webgl.enable-prototype-webgl2 gibt es schon sehr lange nicht mehr. Das stammt aus einer Zeit, als WebGL2 noch ein „Prototyp“ war, wie der Name schon sagt.

Danke für den Hinweis. Da war eine Berechtigung falsch eingestellt. Ich hatte die Grafik gesehen.

Hallo,

rufe bitte about:support auf. Klicke dort auf „Text in die Zwischenablage kopieren“ und füge den Inhalt in deine nächste Antwort ein. Nutze dafür die Funktion „Code-Block einfügen” des Forums.

argsef Wenn du sowieso schon ein Video erstellt hast, wäre es klasse, wenn du das teilen würdest.

jopi56 Ich nehme mal an, diese Seite nutzt Framesets. Das ist ein bekanntes Problem und wird in Firefox 134.0.2 behoben sein. Das klingt aber überhaupt nicht nach dem gleichen Problem wie beim Themenstarter.

Das Script wirft mehrere Fehler in der Konsole. Die zu beheben, muss immer der erste Schritt sein.

Zeile 191:

Uncaught TypeError: can't access property "parentNode", this.historyUndoWindowPopup3 is undefined

In dem Block kommt this.historyUndoWindowPopup3 mehrfach vor, das ist also auch mehrfach zu korrigieren.

Zeile 155:

Uncaught DOMException: String contains an invalid character

Die Meldung ist etwas irreführend. Das „ungültige Zeichen“ ist, dass es gar kein Zeichen gibt. Es liegt nämlich am Aufruf document.createXULElement(""). Ein leerer String als Argument für diese Methode ergibt überhaupt keinen Sinn. Was soll das bedeuten? Ein geheimes Element soll erstellt werden?

Das kommt so drei Mal im Script vor, das muss also auch drei Mal behoben werden. Durch die Fehler in den genannten Zeilen kommt es erst gar nicht zur Ausführung der anderen Fehlerstellen. Im Original-Script wird an diesen Stellen übrigens jedes Mal ein menuseparator-Element erstellt.

Entfernt man alle Fehlerstellen, wird der vermisste Menüeintrag angezeigt.

Ein neuer Artikel wurde veröffentlicht:

Zitat

Mozilla hat Firefox 134.0.1 veröffentlicht und behebt damit mehrere Probleme der Vorgängerversion.

Artikel lesen: „Mozilla veröffentlicht Firefox 134.0.1“

Zitat von BrokenHeart

Ja, so habe ich es ja in dem Beispielcode auch gemacht. Ganz verstehe ich nicht, was du meinst . 'oncommand' und 'onclick' werden nicht in die Attribute geschrieben, sondern stattdessen eben der entsprechende EventListener hinzugefügt mit 'command' und 'click'. Für alle anderen Eigenschaften des übergebenen Objekts wird die vorgegebene Standardzuweisung el.setAttribute(n, attr[n]); verwendet.

Ich hatte nicht gesehen, dass du schon Code dafür hattest. Ich hatte mir nur den Teil des Beitrags angesehen, der an mich gerichtet war. In diesem Thema war so viel in so kurzer Zeit los und ich so beschäftigt, dass ich vermutlich nicht mal die Hälfte des gesamten Themas gelesen habe. 😬

Die Umsetzung, die ich im Kopf hatte, hätte so ausgesehen, dass der Name des Attributs ausgelesen wird und wenn dieser mit „on“ beginnt, der entsprechende Code kommt und für den Event-Namen die ersten zwei Buchstaben gestrichen und der dritte klein geschrieben wird. Das wäre dann auch flexibel genug für andere Events als nur diese zwei. Wenn aber ohnehin nur „oncommand“ und „onclick“ verwendet werden, hast du mit deiner Umsetzung sowieso schon alle Fälle abgedeckt. Das passt also, wie es ist.

eval() gilt vor allem aus Sicherheitsgründen als absolutes No-Go in JavaScript - auf Grund genau dieser Eigenschaft, die hier genutzt wird: aus einem String ausführbares JavaScript zu machen. In der Hinsicht ist der Weg über Function auch nicht besser. Die andere Sache ist, dass für eval() sämtliche Optimierungen der Engine außer Kraft gesetzt sind, was es sehr langsam macht.

Was die Sicherheit betrifft: Wenn du das auf einer Website nutzt und dann möglicherweise noch Nutzer-Eingaben verarbeitest, kann das fatale Folgen haben. In dem Fall denke ich, dass das nicht so viel ausmacht, weil keine Fremdeingaben verarbeitet werden und die Kontrolle vollständig beim Anwender liegt. Würde jemand Drittes Zugriff auf das System haben und das Script manipulieren wollen, wäre das bei einem direkten Aufruf der Funktionen ohne eval() genauso möglich. Dann wird eben das manipuliert.

Möchte man auf eval() oder Function() verzichten, muss man das Script umbauen und ähnlich lösen, wie in den anderen Fällen. Aus Performance-Sicht wäre das empfehlenswert. Und dass Mozilla früher oder später die Verwendung von eval() unterbindet, ist durchaus denkbar. Dafür gibt es ebenfalls eine CSP-Direktive. Zukunftssicherer wäre es definitiv ohne. Aber aktuell funktioniert es damit noch.

Du hast schon Recht. Das ist tatsächlich zur Abwechslung mal ein Fall, der sich nicht automatisch aus den anderen Fällen ergibt, sondern etwas Zusatzwissen benötigt.

In den anderen Fällen hast du immer JavaScript-Funktionen, die innerhalb eines Strings angegeben sind, erkennbar an den Anführungszeichen. Zum Beispiel:

key.setAttribute('oncommand', 'document.getElementById("AMpopup").openPopup();');

Die kannst du einfach aus den Anführungszeichen herausnehmen und dann ausführen:

key.addEventListener('command', () => {
  document.getElementById('AMpopup').openPopup();
});

In dem Fall hast du keine Anführungszeichen:

menuItem.setAttribute("oncommand", item.command);

Das item.command ist quasi eine Variable, die das auszuführende Script beinhaltet. Nun könnte man meinen, das macht keinen Unterschied. Und es wäre, basierend auf den bisherigen Erkenntnissen, folgender Gedanke naheliegend:

menuItem.addEventListener('command', function () {
  item.command;
});

Also gleich, wie es die ganze Zeit mit den Funktionen geschieht. Aber das funktioniert so nicht. Eine Variable kann man nicht einfach so in den Raum stellen, damit etwas passiert.

Die Funktion eval() führt einen Text, in dem Fall also den Inhalt von item.command als Script aus:

menuItem.addEventListener('command', function () {
  eval(item.command);
});

Folgendes würde auch funktionieren:

menuItem.addEventListener('command', function () {
  Function(item.command)();
});

Das ist sogar die bessere Variante, da deutlich performanter.

Zitat von FuchsFan

aber das bekomme ich nicht gerichtet.

Auch hier immer das Gleiche:

ExternalAppBtn.setAttribute("onclick", "event.preventDefault();event.stopPropagation();");
key.setAttribute('oncommand', 'document.getElementById("AMpopup").openPopup();');
appItem.setAttribute('oncommand', "Appmenu.exec(this.path, this.args);");
configItem.setAttribute('oncommand', config.command);

=>

ExternalAppBtn.addEventListener('click', event => {
  event.preventDefault();
  event.stopPropagation();
});

key.addEventListener('command', () => {
  document.getElementById('AMpopup').openPopup();
});

appItem.addEventListener('command', function () {
  Appmenu.exec(this.path, this.args);
});

configItem.addEventListener('command', () => {
  Function(config.command)();
});

Nachtrag: Nummer 4 korrigiert, ich hatte mir das Original-Script nicht gut genug angesehen. Das funktioniert tatsächlich etwas anders.

Zitat von Horstmann

Sieht nicht einfach aus, da haste recht.

Sieht es nicht?

Aus:

element.setAttribute('onEvent', 'function();');

wird:

element.addEventListener('event', () => {
  function();
});

Das ist das ganze Prinzip, welches sich die ganze Zeit wiederholt. Manchmal entstehen wie gesagt Irritationen dadurch, dass es unterschiedliche Schreibweisen gibt. Oder der Code ist etwas „komplizierter“ dadurch, dass Attribute in einer Schleife gesetzt werden, ein Teil der Logik in eine eigene Methode ausgelagert ist und / oder Funktionen ineinander verschachtelt werden. Dann reicht es nicht mehr, nur zu kopieren. Dann muss man den Weg verstanden haben, genau hinsehen und das Gelernte unter abweichenden Voraussetzungen anwenden. Aber das Prinzip bleibt am Ende immer das Gleiche.

Zitat von BrokenHeart

Wenn man sich das gesamte Skript anschaut, ist es dann nicht tatsächlich besser '$C()' (warum dieses überflüssige '$'-Zeichen?) zu verändern und dort den EventListener hinzuzufügen? Sonst müsste man ja zigmal Variablen definieren und jedes Mal einen Eventlistener erstellen. So kann man direkt in der Funktion das gerade erzeugte Element nutzen und es gibt den Code für den Eventlistener für alle Elemente nur einmal.

Die Frage hatte ich übersehen. Man kann natürlich auch diesen Weg gehen. Dann muss man halt in dieser Funktion den Namen der Eigenschaft prüfen und für die on*-Eigenschaften den Listener ensprechend setzen statt das Attribut. Dann darf man nur nicht vergessen, den Namen dynamisch anzupassen, denn das on gehört ja nicht in den Event-Namen und der erste Buchstabe muss klein sein.

Wieso das $ verwendet wird, weiß ich nicht. Wenn ich so etwas sehe, vermute ich als erstes, dass der ursprüngliche Entwickler aus der jQuery-Entwicklung kommt und das daher hat. Aber vielleicht hatte der Entwickler auch eine ganz eigene Konvention, wann er das Dollar-Zeichen verwendet. Das müsste man den Entwickler mal fragen. Schlimmer finde ich, dass Funktionen als $, $A und $C benannt sind. Schön kurz, ja, aber nicht lesbar an den Stellen, an denen die Funktionen verwendet werden.