FF131: Schon wieder funktionieren 2 js-Scripte nicht mehr

    • Neu
    Zitat von Sören Hentzschel

    Der Code in Beitrag #9 ist an mehreren Stellen fehlerhaft, der dürfte so nicht funktionieren: Am Ende von Zeile 10 steht ein Komma statt einer schließenden Klammer und auch in der letzten Zeile wird nicht korrekt geschlossen, was in der ersten Zeile begonnen wurde.

    Schlimm, schlimm. Da habe ich versehentlich in Beitrag #9 das Skript für den Start aus dem Datei-Menü erwischt statt das für den Neustart aus dem Hamburger-Menü. Oh, oh, man wird so langsam alt. Ich bitte alle um Verzeihung.

    Übersetzer für Obersorbisch und Niedersorbisch auf pontoon.mozilla.org u.a. für Firefox, Firefox für Android, Firefox für iOS, Firefox Klar/Focus für iOS und Android, Thunderbird, Pootle, Django, LibreOffice, LibreOffice Onlinehilfe, WordPress

    • Neu

    Ich frage mich ja im Nachhinein, ohne dem vorher in den Scripts hier Beachtung geschenkt zu haben, wieso überhaupt so häufig on*-Attribute via Script gesetzt wurden. Die addEventListener()-Methode wurde bereits in Firefox 1 vor 20 Jahren (!) unterstützt (noch frühere Daten haben die MDN web docs nicht, wahrscheinlich wird es sogar noch länger unterstützt) und war immer der bessere Weg, in JavaScript auf Events zu hören. Bei den on*-Attributen geht es ja darum, Scripts direkt im HTML/XUL unterzubringen, weil man eben keine separate Script-Datei hat. Aber wenn man sich sowieso bereits in einem Script befindet, ist es ja unnötig, das Script erst ins HTML/XUL zu schreiben, sondern kann es auch direkt an der Stelle ausführen. Ein weiterer Nachteil:

    JavaScript
    const button = document.getElementById('button');
button.onclick = function1;
button.onclick = function2;
button.addEventListener('click', function3);
button.addEventListener('click', function4);

    In diesem Beispiel werden function2, function3 und function4 ausgeführt, aber function1 nicht. Denn jedes Attribut kann es nur ein einziges Mal geben, bei mehrfacher Verwendung überschreibt man also die Funktion. Das passiert bei addEventListener() nicht, was auch erklären kann, wieso vielleicht zwei unterschiedliche Scripts, die das gleiche Element betreffen, nicht gemeinsam funktionieren.

    Und dazu kommt das bereits erwähnte leichtere Schreiben von Code ohne das „\“ nach jeder Zeile sowie Syntax-Highlighting hier im Forum. Und bei Verwendung eines entsprechenden Programms ggf. Unterstützung dadurch wie Code-Vorschläge oder Hervorhebung von Fehlern, was ja nicht möglich ist, wenn das Script nicht als Script erkannt wird, sondern nur als einfacher Text ausgezeichnet ist.

    • Neu
    Zitat von Sören Hentzschel

    Die addEventListener()-Methode wurde bereits in Firefox 1 vor 20 Jahren (!) unterstützt

    Nicht, dass ich mich gut auskenne, aber belegt nicht jeder eventListener etwas Speicherplatz? Das war dann schon ein Kriterium, lieber onclick zu verwenden. (Ja, das Skript selbst wird ebenso in den Speicher geladen …)

    Ergänzung: Ich lese gerade, dass der IE kein addEventListener beherrschte. dann war onclick für Autoren bequemer und mag später aus Gewöhnung weiter benutzt worden sein.

    • Neu
    Zitat von Speravir

    aber belegt nicht jeder eventListener etwas Speicherplatz?

    Wenn man stattdessen ein Attribut im HTML nutzt, ist das ja auch ein Eventlistener. Ich wüsste nicht, wieso das vo dem Aspekt her einen Unterschied machen sollte. So oder so ist das nicht wahrnehmbar, vermutlich nicht einmal messbar. Das, was wirklich Einfluss auf die Performance hat, ist der Code, der dann letztlich ausgeführt wird, unabhängig von der Methode, den Eventlistener zu registrieren.

    Zitat von Speravir

    Ich lese gerade, dass der IE kein addEventListener beherrschte. dann war onclick für Autoren bequemer und mag später aus Gewöhnung weiter benutzt worden sein.

    Der Internet Explorer kannte bis einschließlich Version 8 kein addEventListener, dafür attachEvent. Man hätte sich auch damals einfach eine Funktion schreiben können, die intern dann entweder die eine oder die andere Methode aufruft. Und seit Version 9 kannte auch der Internet Explorer addEventListener.

    Zu der Zeit hat man in der Webentwicklung aber sowieso meistens auf jQuery gesetzt, um sich um die Kompatibilität keine Sorgen machen zu müssen. Insofern weiß ich nicht, ob Gewöhnung wirklich ein Thema war, denn jQuery funktioniert ja auch sichtbar anders als „Vanilla JavaScript“. ;)

    • Neu

    Heißt das, das alle onclick Beschreibungen in Scripts in addEventListener umzuschreiben sind?
    Siehe z. B. hier: Zeile 480 und 495

    • Neu

    Ich will es so formulieren: Sollte Mozilla eine Sicherheits-Richtlinie einführen, die das Setzen dieser Attribute verbietet, was geplant zu sein scheint, aber noch nicht der Fall ist, und sollte diese Richtlinie dann auch dann greifen, wenn die Attribute via JavaScrpit gesetzt werden und nicht nur bei direkter Verwendung im HTML, was gut sein kann, worüber ich mir aber nicht sicher bin, dann muss das entsprechend geändert werden, sobald das passiert. Vorher kann man es ändern, wenn man möchte.

    • Neu

    Vielen Dank, da das hier bei einigen Scripts vorhanden ist, werde ich es lieber gleich ändern. Wäre dann oben z. B. die Zeilen 480 bis 495
    so zu ändern?

    also quasi ein 1 zu 1 Austausch?

    • Neu

    Nein, so nicht. Ich kann's nicht testen, weil nicht einmal der Originalcode bei mir funktioniert, wenn ich ihn in der Konsole so ausführe. Aber versuche es für die Zeilen 472 bis 501 mal damit:

    • Neu

    Hallo alle zusammen und speziell Sören,

    Zitat von Sören Hentzschel

    Vorher kann man es ändern, wenn man möchte.

    wenn das so ist, dann würde ich gerne mal von Euch dort ↓ einen Blick geworfen haben.

    Nach meinem Editor ist oncklick ab Zeile 108 zu finden.

    Ich hoffe es wird sich jemand finden bzw. erbarmen und dieses Script für die Zeit nach oncklick lauffähig zu halten, ich danke schon einmal vorab dafür.

    Es grüßt,

    Ralf

    • Neu

    Zeile 108 passt, da es die onClick-Methode der CustomizableUI.createWidget-API ist. Aber die Zeilen 142-155 setzen ein entsprechendes Attribut für ein XUL-Element und können hiermit ersetzt werden: