Beiträge von Sören Hentzschel

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.

In den meisten Fällen ist es so einfach. Aber das heißt nicht, dass sich jeder damit leicht tut, das von einem Fall auf den nächsten zu übertragen, insbesondere wenn die Scripts teilweise unterschiedliche Methoden und Schreibweisen verwenden und man selbst nicht regelmäßig mit JavaScript arbeitet und daher nicht einordnen kann, was das Gleiche bewirkt und was etwas anderes.

Ab Firefox 135 wird es möglich sein, Native Messaging in Snap-Builds von Firefox zu verwenden, wenn widget.use-xdg-desktop-portal.native-messaging den Wert 1 oder 2 hat und das XDG Desktop Portal in mindestens Version 1.19 vorhanden ist - diese Version ist noch unveröffentlicht. Ubuntu hat die Unterstützung bereits in Version 22.04 inkludiert. Ob das damit auch für Lubuntu gilt, weiß ich nicht.

Zitat von Horstmann

Vielleicht steh ich hier mal wieder auf dem Schlauch, aber ist es nicht sowas , oder ist das zu einfach gedacht?
Also dem gewünschten Element weist man die gewünschte Funktion zu, via addEventListener?

Mir ist ehrlich gesagt nicht klar, ob ich deine Frage richtig verstehe. Aber ja, es geht in diesem Thema um genau diese Inline-Eventlistener, die mittels addEventListener-Aufrufe ersetzt werden.

Ein neuer Artikel wurde veröffentlicht:

Zitat

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

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

Zitat von Sören Hentzschel

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.

Um zu unterstreichen, dass das nicht nur Gerede ist, haben wir hier einen aktuellen Beleg dafür, welche Probleme es bereitet, wenn man ein Firefox-Profil mit unterschiedlichen Firefox-Versionen nutzt:

Dies hat für Nutzer von Firefox 134 dazu geführt, dass keine Suchen mehr ausgeführt werden konnten und auch die Kontextmenüs defekt waren.

Zitat von Endor

Sobald ich es bei allen so ändere geht das Script aber nicht mehr.

Zeile 62:

UCL.editUserCSS(\'userChrome.css\');

/* wird zu => */

UCL.editUserCSS('userChrome.css');

Ähnlich Zeile 71. Und nach Zeile 108 fehlt das Komma.

Das sind erst einmal nur die Syntax-Fehler, die behoben werden müssen, damit das Script erfolgreich ausgeführt werden kann. Und insgesamt zähle ich immer noch drei Inline-Listener.

Zitat von Endor

Bei: onclick: "if (event.button == 1) UCL.rebuild()"

Gleiches Prinzip:

const cssmenu = $C("menu", {
  id: "usercssloader-menu",
  label: "CSS",
  tooltiptext: "UserCSSLoader\n\nLinksklick: Stylesheets anzeigen\nMittelklick: Styles importieren",
  accesskey: "C",
  onclick: "if (event.button == 1) UCL.rebuild()"
});

/* wird zu => */

const cssmenu = $C("menu", {
  id: "usercssloader-menu",
  label: "CSS",
  tooltiptext: "UserCSSLoader\n\nLinksklick: Stylesheets anzeigen\nMittelklick: Styles importieren",
  accesskey: "C"
});

cssmenu.addEventListener('click', event => {
  if (event.button === 1) {
    UCL.rebuild();
  }
});

„Alle Tabs auflisten“ ist das Panel, welches sich bei Klick auf die Schaltfläche mit dem Pfeil in der Tableiste öffnet. Das möchte der Themenstarter per Tastatur öffnen.

Hallo,

um welche Information konkret geht es dir? Veränderte Berechtigungen siehst du auch in Firefox für Android nach Klick auf das Schloss-Symbol, ebenso eine Information zum Zertifikat (wenn auch nicht ausführlich) oder die Funktion zum Löschen der Cookies und Website-Daten. Eine Auflistung aller verwendeten Medien gibt es hingegen nicht.

Zitat von Endor

Wie muss ich da die Zeile mit oncommand ändern?

Ungetestet:

const menuitem = $C('menuitem', {
  label: 'CSS Datei erstellen',
  accesskey: 'D'
});

menuitem.addEventListener('command', () => {
  UCL.create();
})

mp.appendChild($C('menuseparator'));
mp.appendChild(menuitem);

Das $C() ist eine Methode, die vom Script selbst definiert wurde. Wenn die Funktion selbst nicht verändert werden soll, kann man das Element nutzen, welche die Methode zurück gibt. Weist man den Rückgabewert einer Variablen zu, kann man darauf dann addEventListener ausführen.

Zitat von 2002Andreas

Aber hier funktioniert das so nicht

Das kann schon sein, dass das in diesem Fall nicht zum gewünschten Ergebnis führt. Ich hatte das für diese Mediathek nicht getestet. Ich wollte damit nur aussagen, dass es technisch keinen Zusammenhang zwischen MSE und dem Videoformat gibt und das halt bei dieser Mediathek, bedingt durch deren Implementierung, eher zufällig zu deinem Ziel führt, weil es bei dieser Option eigentlich um etwas anderes geht. Meine Nennung des Schalters für WebM war an der Stelle zugegeben irreführend, wenn es in dem Fall nicht das gleiche Ergebnis bringt.

Zitat von 2002Andreas

Ich brauche es aber .mp4 für meinen TV. Dann muss ich den config Eintrag umschalten, dann wird es eine .mp4 Datei:

In dem Fall klappt das also eher zufällig. Die Unterstützung für WebM könntest du auch über media.webm.enabled steuern. Der Schalter media.mediasource.enabled steuert die Unterstützung sogenannter Media Source Extensions. Dass sich das ausgelieferte Format dadurch ändert, ist eine Entscheidung, die diese Mediathek getroffen hat. Technisch gesehen gibt es da keinen Zusammenhang. Das heißt, es könnte theoretisch irgendwann passieren, dass du doch wieder WebM-Videos bekommst.

Zitat von Mira_Belle

D.h. ich könnte den Code auch so verwenden?

Wenn es funktional identisch zur anderen Version sein soll, ja. Wenn diese Abfrage einen Grund hat, kannst du sie natürlich auch belassen.

Zitat von Mira_Belle

Und die Variable auch "Sören" nennen?

Umlaute (oder allgemeiner: Nicht-ASCII-Zeichen) sollten vermieden werden. Aber grundsätzlich möglich, ja.

Die Beschreibung darunter fasst zusammen, was darunter fällt: Berechtigungen und Website-Einstellungen. Also Dinge wie Autoplay, Cookie-Ausnahmen etc. Daran hat sich aber auch nichts geändert. Die Funktion „Website vergessen“ vergisst alles, was mit dem Verlauf der Website zusammenhängt, einschließlich Chronik, Formulardaten, Cookies, Cache usw.