userChrome.js Scripte für den Fuchs (Diskussion)

Zitat von Endor

Das Schaltflächensymbol wird auch nicht angezeigt.

Kann nicht, weil ich nicht das Original verwende.

Mit dem Fehler Zeile 114 kann ich überhaupt nichts anfangen userChromeJS/utilities.js:114

Zitat von FuchsFan

Mit dem Fehler Zeile 114

Den habe ich in allen meinen Skripten

                .loadSubScriptWithOptions(userChrome.getURLSpecFromActualFile(aFile),

Zitat von Endor

Dein Script haut bei mir gleich mehrere Fehler raus:

Code

Uncaught NS_ERROR_FILE_NOT_FOUND: Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIFile.directoryEntries]
    getCss file:///C:/Users/xxx/AppData/Roaming/Mozilla/Firefox/Profiles/9l0hyy5o.test/chrome/extraconfigmenu.uc.js:427
    init file:///C:/Users/xxx/AppData/Roaming/Mozilla/Firefox/Profiles/9l0hyy5o.test/chrome/extraconfigmenu.uc.js:114
extraconfigmenu.uc.js:427
Uncaught NS_ERROR_FILE_NOT_FOUND: Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIFile.directoryEntries]
    getCss file:///C:/Users/xxx/AppData/Roaming/Mozilla/Firefox/Profiles/9l0hyy5o.test/chrome/extraconfigmenu.uc.js:427
    init file:///C:/Users/xxx/AppData/Roaming/Mozilla/Firefox/Profiles/9l0hyy5o.test/chrome/extraconfigmenu.uc.js:114
2 extraconfigmenu.uc.js:427
    getCss file:///C:/Users/xxx/AppData/Roaming/Mozilla/Firefox/Profiles/9l0hyy5o.test/chrome/extraconfigmenu.uc.js:427
    init file:///C:/Users/xxx/AppData/Roaming/Mozilla/Firefox/Profiles/9l0hyy5o.test/chrome/extraconfigmenu.uc.js:114
Uncaught TypeError: menu is null
    init file:///C:/Users/xxx/AppData/Roaming/Mozilla/Firefox/Profiles/9l0hyy5o.test/chrome/extraconfigmenu.uc.js:89
    <anonymous> file:///C:/Users/xxx/AppData/Roaming/Mozilla/Firefox/Profiles/9l0hyy5o.test/chrome/extraconfigmenu.uc.js:567
    loadScript file:///C:/Program Files/Mozilla Firefox/userChromeJS/utilities.js:114

Alles anzeigen

Die NS_ERROR_FILE_NOT_FOUND-Fehler kommen, wenn auf Ordner zugegriffen werden soll, die nicht existieren. Das sind in dem Script konkret die Ordner Scripte, CSS, CSSWeb und CSSAbout. Wenn die angelegt sind, gibt es diese Fehler auch nicht.

Zitat von Sören Hentzschel

Nach Möglichkeit sollte immer === verwendet werden.

Notwendig, weil JS über nur über die fehleranfällige 'dynamische Typisierung' verfügt, die Ursache vieler Fehler ist. Einerseits ist JS so verzeihend, dass alles irgendwie mit allem verglichen werden kann, andererseits werden dann wieder "strict"-Anweisungen bzw Operatoren wie "===" nachträglich (2015!) hinzugefügt, damit der Wildwuchs nicht zu groß wird. Daher resultiert auch die unterschiedliche Qualität der meisten Skripte. Die wenigen Vorgaben, die diese Sprache macht und die dynamischen Optimierungen verleiten dazu, dass jeder quasi seinen eigenen "privaten Code" in JS schreiben kann (ist in 'C' leider ähnlich). Daher gibt es auch kaum eine Sprache, die schwerer zu lesen ist als JS (mal von irgendwelchen experimentellen oder spaßhaften Sprachen abgesehen).

Die Hinweise, die du zur "Codequalität" bringst sind zwar richtig, aber für mich irgendwie nur ein Pflaster für eine konzeptionell überholte Sprache.

Lustig(?) "Wtfjs":

wtfjs - a little code blog about that language we love despite giving us so much to hate

Zitat von BrokenHeart

aber für mich irgendwie nur ein Pflaster für eine konzeptionell überholte Sprache.

Das sehe ich komplett anders. Vor allem finde ich, dass diese Aussage der Sprache in ihrer heutigen Form nicht gerecht wird. JavaScript hat sich in den letzten Jahren massiv weiterentwickelt und ist mittlerweile so mächtig, dass JavaScript längst auch als serverseitige Programmiersprache und sogar für komplexe Spiele verwendet werden kann. Auch vom Firefox-Code ist Stand heute mehr als ein Viertel JavaScript. Dem wäre nicht so, wäre JavaScript tatsächlich eine „überholte Sprache“.

JavaScript hat historisch bedingte Design-Schwächen, aber derer muss man sich nur bewusst sein und die „guten“ Wege nutzen, Dinge umzusetzen. Das eigentliche Problem ist das gleiche wie mit HTML oder CSS und hat nichts mit der Sprache an sich zu tun: Es ist aus Kompatibilitätsgründen nicht möglich, grundsätzliche Schwächen zu korrigieren. Denn was einmal draußen in der Welt in Verwendung ist, muss auch in 20 Jahren noch funktionieren. Das ist das Konzept des Webs. So etwas wie eine „Deprecation“ für ein bestimmtes Konstrukt und in einem Jahr muss jeder seinen Code angepasst haben, ist (fast) nicht möglich. Selbst, wenn Dinge aus dem Standard entfernt werden, müssen sie trotzdem dauerhaft weiter unterstützt werden. Ausnahmen bestätigen die Regel, dann auch meist nur, wenn die Nutzung wirklich extrem gering ist. Aber niemand ist gezwungen, sein JavaScript heute auf dem Standard von vor 20 Jahren zu schreiben. Schon gar nicht in Scripts für Firefox, für die Kompatibilität mit anderen Browsern völlig egal ist und man wirklich Gebrauch von allen modernen Vorgehensweisen machen kann.

Zitat von Sören Hentzschel

Das sehe ich komplett anders.

[...]

Dem wäre nicht so, wäre JavaScript tatsächlich eine „überholte Sprache“.

Ich glaube gar nicht, dass du das so komplett anders siehst . Ich hatte geschrieben "konzeptionell überholte Sprache". Die Kompatibilitätsproblematik hat man bei sehr vielen Sprachen bzw. überall da, wo stark verbreitete Software eingesetzt wird (z.B. windows). Das ist zwar unschön, aber auch kaum vermeidbar. Wenn in sehr "alten" Sprachen bestimmte Konzepte nicht verwirklicht wurden, wie in 'C' (ca. 1970) oder Fortran (1957), dann ist das natürlich verzeihlich, weil sie in einer Zeit mit anderen Anforderungen entwickelt wurden, wo diese Konzepte noch nicht, oder nur als theoretische oder experimentelle Ideen im akademischen Bereich existiert haben. Aber als JavaScript erschienen ist (1995), gab es diese Konzepte schon und zwar als nutzbare Programmiersprachen z.B. C++, Java etwa zeitgleich.

Ich will JavaScript gar nicht schlecht machen. Die Sprache ist nun mal da, wird auch noch weiterentwickelt (was gut ist!) und ist extrem weit verbreitet. Das ist der status quo und daraus sollte man eben das Bestmögliche machen. Ich bin ja auch nicht der Meinung, dass deine Hinweise falsch sind, haben für mich persönlich nur eine andere Priorität.

Betrifft die Error-Meldung in dem genannten Script:

Beitrag

RE: userChrome.js Scripte für den Fuchs (Diskussion)

[…]

(Quelltext, 568 Zeilen)

Hier sind es die Zeilen 89 und 567.

FuchsFan

16. Januar 2025 um 10:28

Da wird ja die Zeile 89 gemeldet, die in dem Code für den verschiebbaren Button liegt.

// als verschiebbaren Button anlegen
      if (window.__SSi == "window0") {
        CustomizableUI.createWidget({
          id: "ExtraConfigMenu-button",
          defaultArea: CustomizableUI.AREA_NAVBAR,
          label: "Extra Config Menü",
          tooltiptext: "Extra Config Menü\nRechtsklick \öffnet about:config"
        });
		
      }
      var menu = document.getElementById("ExtraConfigMenu-button");
      menu.setAttribute("type", "menu");
	  menu.addEventListener('click', function(event) {
			if (event.button == 2 && !this.open) { 
				openTrustedLinkIn("about:config", "tab");
				event.preventDefault();
			};
	 },true);
	  
    } 

Wird der Code deaktiviert, und das Original verwendet, dann gibt es keine Fehler mehr.

Was müsste in besagter Zeile menu.setAttribute("type", "menu"); geändert werden?