Beiträge von Sören Hentzschel

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.

Zitat von Mira_Belle

Warum muss mp.setAttribute("onpopupshowing", "UCT.onpopupshowing(event);"); behandelt werden,
als wäre es doch ein "EventListener"? (Das Skript funktioniert sonnt nicht!

Gegenfrage: Wieso sollte hier etwas anderes gelten?

Zitat von Mira_Belle

Worin bestehen die Vor, bzw. Nachteile der jeweiligen Versionen?

Ob du die Variable id oder index nennst, macht keinen Unterschied (um Bezug auf deine Code-Kommentare zu nehmen). Du kannst die nennen, wie du möchtest. Ansonsten, unter der Voraussetzung, dass beides gleich funktioniert (ich habe es nicht getestet), ist der Vorteil deiner Version, dass sie weniger umständlich ist. Es liest sich besser, außerdem wird die Funktion wirklich als Funktion und nicht als String geschrieben (was schon ein Nachteil der Inline-Variante war), womit Syntax-Hervorhebung und Navigation im Code-Editor möglich sind. Und das hilft letztlich dabei, den Code zu verstehen und zu pflegen. Die Bedingung event.button == 0 ist im Übrigen bereits zusätzlicher Code, das gibt es im anderen Code nicht. Lässt du das weg, wird der Unterschied noch deutlicher.

Der Begriff beschreibt den Zustand, dass der Benutzer kürzlich mit der Website interagiert hat, zum Beispiel, indem ein Link angeklickt worden ist. Stunden später gilt ein Klick natürlich nicht mehr als Aktivierung durch den Benutzer. Tatsächlich liegt die Zeit bei knapp unter fünf Sekunden. Das ist deswegen ein relevantes Konzept für den Browser, weil es Funktionen der Webplattform gibt, die nicht von alleine starten dürfen, sondern eine Aktivierung durch den Benutzer verlangen.

Was genau da nun technisch in diesem Zusammenhang geändert worden ist, ist für das Problem des Themenstarters nicht so wichtig. Aus Nutzersicht ist der schöne Nebeneffekt in den offiziellen Release Notes erklärt: „Firefox now follows the model HTML specification for transient user activation more closely. This change makes popup blocking less strict in cases where previous versions of Firefox were overly aggressive, reducing erroneous blocking prompts.“

Was das mit der Frameset-Navigation zu tun hat? Richtig: aus Nutzersicht gar nichts. Aber die ganze Maschinerie für die Navigation ist natürlich extrem komplex, deckt einen Haufen verschiedener Anwendungsfälle ab und beinhaltet viele Sicherheits-Prüfungen, wie man sich vorstellen kann. Das ist eine der sicherheitsrelevantesten Browserkomponenten. Und in diesem Fall hatte eine Änderung zur Folge, dass bei der Navigation zwischen lokalen Dateien in Framesets dieses nicht mehr als gleiche Domain erkannt worden sind und die Navigation daher blockiert wurde.

Es hat am Ende doch etwas länger gedauert. Aber Firefox 136 bietet das Löschen von Formulardaten wieder unabhängig von der Chronik an.

Zitat von .DeJaVu

Für mich ist die Änderung eine Änderung bei der Sicherheit, die unter diesen Umständen nicht mehr geladen wird. Also habe die da zu viel an der Stellschraube gedreht oder file:/// vergessen?

Die erfolgte Änderung hatte nie die Absicht, etwas in Bezug auf die Navigation von Framesets zu verändern oder den lokalen Zugriff einzuschränken.

Kontext ist ein Verhaltensunterschied in Bezug auf die Transient Activation zwischen Blink, Webkit und Gecko. Das wurde innerhalb der WhatWG besprochen und man hat das gewünschte Verhalten in die HTML-Spezifikation aufgenommen. Mozilla hat dann die entsprechende Änderung für Gecko vorgenommen. Das Problem des Themenstarters war einfach eine ungewollte Nebenwirkung von Mozillas Code-Änderung, weil die Frameset-Navigation an einer entscheidenden Stelle vom gleichen Code betroffen ist und damit eine Verhaltensänderung eingeführt wurde, die nicht gewollt war.

Zitat von H_J_M

Ich hoffe, daß der in #10 erwähnte Bug in Firefox 134 bald korrigiert ist, damit ich dem Firefox-Browser treu bleiben kann.

Der Fehler wird voraussichtlich in Firefox 134.0.2 behoben sein, dessen Veröffentlichung für den 21. Januar geplant ist.

Zitat von .DeJaVu

Ursache ist die Erhöhung der lokalen Sicherheit, und Framesets haben sich schon vor 20 Jahren überholt.

Auf die Gefahr hin, dass ich wieder etwas falsch verstanden habe, aber Ursache für das Problem des Themenstarters ist ein Bug in Firefox. Das war keine gewollte Änderung zur Erhöhung der Sicherheit. Und HTML5, womit Framesets als obsolet eingestuft worden sind, ist in der finalen Fassung im Übrigen auch erst zehn und noch keine 20 Jahre alt. Nicht, dass das überhaupt wichtig wäre. Würde man damit anfangen, für jede Website hohe Standards vorauszusetzen, würde es den größten Teil des Webs überhaupt nicht mehr geben.

Zitat von Webmark

Weshalb steht dieses Thema eigentlich auf gelöst?

Der Themenstarter war vier Tage inaktiv, ehe er wieder in diesem Thema schrieb. In der Zwischenzeit werden Themen dann als erledigt markiert, weil wir nicht davon ausgehen können, dass die Themen weiter verfolgt werden (meistens ist es nämlich nicht so). Würden wir die Themen dann nicht entsprechend markieren, wäre die Funktion, unerledigte Themen anzuzeigen, nicht zu gebrauchen, weil dann so viele Theme unerledigt wären, von denen man nicht weiß, in welchen Hilfe noch relevant ist und in welche nicht.

Ich habe hier den Status wieder entfernt.

Weil ich es hier ein paar Mal gesehe habe: Die Angabe von false am Ende von addEventListener ist nicht notwendig. Das ist der Standardwert. Das ist also beides das Gleiche:

foo.addEventListener('eventname', event => {

}, false);

foo.addEventListener('eventname', event => {

});

Bezüglich der Firefox-Version, die das betrifft: Nicht zwingend Firefox 136. Die CSP ist erst einmal nur in Nightly-Versionen aktiv und Mozilla sammelt Telemetrie-Daten über Fehler, die das verursacht.

Zitat von milupo

Wenn im auszuführenden Code event vorkommt, kann man offensichtlich event => verwenden. Aber dieser zweite Parameter kann auch eine Funktion sein. Und hier wird ja eine Funktion ausgeführt.

Wie die Funktionsparameter benannt sind, ist völlig egal. Du kannst den Parameter auch milupo statt event nennen. Was gemeint ist, ergibt sich aus der Position.

Die Schreibweise mit dem => macht daraus eine sogenannte Arrow Function. Es gibt im Vergleich zu „traditionellen“ Funktionen ein paar Detailunterschiede. In den meisten Fällen (und vor allem in den Fällen, um die es hier geht), ist es komplett egal, was man verwendet:

foo.addEventListener('eventname', function () {

});

foo.addEventListener('eventname', () => {

});

oder mit Parameter:

foo.addEventListener('eventname', function (event) {

});

foo.addEventListener('eventname', (event) => {

});

foo.addEventListener('eventname', event => {

});

Bei genau einem Parameter sind die Klammern bei Arrow Functions optional, daher habe ich hier einfach mal beide Schreibweisen geschrieben, damit keine Verwirrungen entstehen, wenn es mal so und mal so geschrieben wird.

Zitat von katzi

Nein, das benenne ich nicht, und "Original" ist "Original", da es ja nur 1 Original hat?

Es gibt verschiedene Linux-Builds. Ist es denn wirklich so schwer, eine mittlerweile nun mehrfach gestellte Frage einfach zu beantworten, statt eine komplett sinnlose Diskussion über die Frage zu führen?