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

    FuchsFan

    Dein Script haut bei mir gleich mehrere Fehler raus:

    Das Schaltflächensymbol wird auch nicht angezeigt.

    Mfg.
    Endor

    Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0.2
    OS: Windows 10 pro 64 bit und Windows 10 Home 64 bit
    Meine Scripte Sammlung: https://github.com/Endor8/userChrome.js
    Kein Support per PN. Fragen bitte im Forum stellen!

    Zitat von Endor

    Dein Script haut bei mir gleich mehrere Fehler raus:

    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

    Gruß BrokenHeart

    "success has many fathers, failure is an orphan"

    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.

    Gruß BrokenHeart

    "success has many fathers, failure is an orphan"

    Betrifft die Error-Meldung in dem genannten Script:

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


    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?

    Grüße vom FuchsFan

    Zitat von BrokenHeart

    Ich glaube gar nicht, dass du das so komplett anders siehst ;) . Ich hatte geschrieben "konzeptionell überholte Sprache".

    Schon, weil ich dieser Aussage eben übehraupt nicht zustimme. ;) Es gibt nicht „das eine“ Konzept. JavaScript nur mit den Möglichkeiten von vor 20 Jahren war natürlich eingeschränkt. JavaScript als Ganzes ist deswegen konzeptionell keineswegs überholt. Denn heute kennt JavaScript viele moderne Konzepte. Es liegt, wie in so ziemlich jeder Sprache, am jeweiligen Entwickler, welche Konzepte genutzt werden.

    Zitat von BrokenHeart

    Die Kompatibilitätsproblematik hat man bei sehr vielen Sprachen bzw. überall da, wo stark verbreitete Software eingesetzt wird (z.B. windows).

    Gegenbeispiel: Je nach Statistkk nutzen ca. 75 bis 80 Prozent aller Websites PHP als serverseitige Sprache. Pro Jahr gibt es eine neue „große“ PHP-Version. Und mit jedem dieser großen Updates gibt es Deprecations und entfernte Features, und davon gar nicht mal so wenige. In PHP geschriebene Software muss aus diesem Grund regelmäßig aktualisiert werden, um mit neuen PHP-Versionen kompatibel zu sein. Das ist also sehr wohl auch möglich, wenn eine Sprache und / oder eine Software weit verbreitet ist. Auch andere bedeutsame Sprachen wie C++ oder Rust kennen Deprecations.

    Die Kompatibilitätsgeschichte für HTML, CSS und JavaScript ist besonders, denn hier ist das mehr oder weniger „verboten“ und alles, was einmal unterstützt wird, muss quasi „für immer“ unterstützt werden. Wie gesagt, Ausnahmen bestätigen die Regel. Aber normalerweise gibt es das nicht. Selbst einzelne Methoden zu entfernen oder gar nur zu verändern, ist in der Vergangenheit mehr als einmal gescheitert. Da brauchen wir von einer Veränderung grundlegender Konzepte wie beispielsweise dem Typen-System gar nicht zu träumen. Man kann natürlich neue Wege schaffen, zum Beispiel, indem man TypeScript schreibt, was ich sehr empfehlen kann. Aber das „normale“ Verhalten von JavaScript ist de facto für immer unveränderlich. Und das gilt meines Wissens für keine andere Sprache als JavaScript, HTML und CSS auch nur ansatzweise in dem Ausmaß.

    Bookmarklets zum Scroll auf der Seite nach oben und unten bis zum Ende. Der erste Klick scroll die Seite von der aktuellen Position bis zum Ende, der zweite Klick bringt die Seite wieder an die vorherige Position. Die Bookmarklets müssen Top und Bottom genannt werden.
    URL für Top

    Code
    javascript: ((t, sy) => {
   if (sy === 0) {
       window.scrollTo({top: window.s_ud, behavior: t});
       s_ud = 0;
   } else {
       s_ud = sy;
       window.scrollTo({top: 0, behavior: t});
   }
})("smooth", window.scrollY)

    URL für Bottom

    Code
    javascript:((t, smy, sy) => {
   if (Math.abs(smy - sy) < 2) {
       if (window.s_du === undefined) return;
       window.scrollTo({top: s_du, behavior: t});
       s_du = smy;
   } else {
       s_du = sy;
       window.scrollTo({top: smy, behavior: t});
   }
})("smooth", window.scrollMaxY, window.scrollY)

    userChrome.css

    Code
    /* Boormarklets "Top" and "Bottom" */
toolbarbutton.bookmark-item[scheme="javascript"]:not([container]) {
 &[label="Top"] {
   content: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAT0lEQVQ4je3Quw4AEAxG4b+e3OitaxEJejUZNLFIz5cAGMNAZaBZO17M4+SQLc4hShxDnNhGgrGMJOMVuYwnQspzWLon4Ngv5q8G5gMvAB00SYnQZbsYoQAAAABJRU5ErkJggg==");
 }
 &[label="Bottom"] {
   content: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAWElEQVQ4je3OsQ6AMAiE4R9f2pG++TmZNEgrbA6SsNC7LzWSESi7G1i8HVmwMz/wCUBwCjTvKhxzAr8fHkhhPeodxLMfVpG8XET25RekVl4gvfKEDMHYZS5D631YXYCxXQAAAABJRU5ErkJggg==");
 }
}

    Was zum Thema "Restart Button":

    Ich vermute, dass das RestartButton-Skript, welches einen Button erzeugt um Firefox neu zu starten und optional den ScriptCache zu löschen, von sehr vielen Skript-Anwendern genutzt wird. Anscheinend gibt es da sehr viele Versionen. Wegen einer anderen Sache habe ich mir dann mal mein Neustarten-Skript genauer angeschaut und festgestellt, dass ich wahrscheinlich schon seit Jahren ein Skript nutze, was nicht genau das macht, was es verspricht. Das Skript welches ich genutzt habe behauptet (z.B. auch in den Tooltips), dass über die "Rechte Maustaste" ein Neustart + Löschen des ScriptCache erfolgt, was aber überhaupt nicht der Fall ist. Ich hatte mich dummerweise darauf verlassen X/. Nur mit der mittleren Maustaste wird der ScriptCache wirklich gelöscht, aber damit erfolgt kein Neustart.

    Entweder ist meine Version wirklich uralt und nur ich bin betroffen. Oder sehr viele, vielleicht sogar alle Nutzer haben dieses unerkannte Problem. Wäre vielleicht ganz gut, wenn ein paar Nutzer des Skripts mal ihre Version hier posten würden..

    Lange Rede... Ich habe mein Skript jetzt mal angepasst und den Mittelklick rausgeschmissen (hat ja nichts mit 'Restart' zu tun), den Text der Tooltips neu verfasst und die Funktion der rechten Maustaste geändert, so dass jetzt wirklich überprüfbar das ScriptCache-Verzeichnis gelöscht wird. Ich habe sonst keine "Code-Verschönerungen" vorgenommen und ein irrsinnig großes Icon verwendet. Wer will kann das natürlich alles ändern. ;)

    Gruß BrokenHeart

    "success has many fathers, failure is an orphan"

    Einmal editiert, zuletzt von BrokenHeart (24. Januar 2025 um 21:40)

    Zitat von BrokenHeart

    Wäre vielleicht ganz gut, wenn ein paar Nutzer des Skripts mal ihre Version hier posten würden..

    Nun habe ich doch in Nightly mein genutztes Script überprüft, rechte Maus, Cache wird gelöscht. Hier dann mal die Version des Scriptes:

    Grüße vom FuchsFan

    Zitat von BrokenHeart

    mal ihre Version hier posten würden..

    Diese hatte ich lange Zeit:

    Jetzt nutze ich diese, die erstellt im Hamburgermenü auch einen Eintrag:

    FuchsFan & 2002Andreas .

    Vielen Dank für das Posten eurer Version.:thumbup:

    Ich muss leider feststellen, dass ihr beide funktionierende Skripte nutzt und nur ich mich aus Faulheit nie mit meinem genutzten Skript beschäftigt habe. :cursing:

    Na ja, jetzt funktioniert es auch bei mir. Besser spät als nie. :(

    Zitat von grisu2099

    Da greif ich doch gleich mal zu...

    Kannst du gerne machen :), aber die Skripte von FuchsFan und 2002Andreas bieten noch mehr Möglichkeiten (Menü).

    Gruß BrokenHeart

    "success has many fathers, failure is an orphan"

    Einmal editiert, zuletzt von BrokenHeart (24. Januar 2025 um 22:03) aus folgendem Grund: Ein Beitrag von BrokenHeart mit diesem Beitrag zusammengefügt.

    Ich nutze noch dieses:

    Das ist wohl das gleiche, welches Andreas früher genutzt hat. Die beiden anderen Varianten für – das Hamburger-Menü und das Menü Datei – habe ich als eigene Skripte. Ich hoffe die sorbischen Texte für label: und tooltiptext: erschweren nicht das Verständnis meines Skriptes. :)

    Ü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