Hallo,
mir ist nicht klar, worauf genau du dich mit „bookmarks“ beziehst, weil es einige Orte in Firefox gibt, die mit Lesezeichen zu tun haben. Diese Art von Erweiterung ist jedenfalls schon lange nicht mehr möglich, da lässt sich nichts machen. Vielleicht beschreibst du stattdessen, was genau du gerne geändert haben möchtest. Vielleicht lassen sich dafür dann Lösungen finden.
Hallo,
Was ich aber nicht hinbekomme, ist die sidebar größer und kleiner zu ziehen?
Der Splitter zum anpacken fehlt.
Dafür musst du auf Firefox 135 warten. Dann wird das möglich sein.
Naja, aber auch nur teilweise. Das war auch darauf bezogen: 
Wenn man aus dem Skript nur eine Funktion braucht, dann sind das nur 17 Zeilen die benötigt werden.
Das von mir zur Zeit genutzte Skript External Applications uc.js hat dafür aber 127 Zeilen.
Den Performance-Aspekt hat BrokenHeart ja schon beantwortet. Ich gehe jetzt bei einem klassischen Firefox-Script auch nicht davon aus, dass man die Auswirkungen des nicht „aufgeräumten“ Scripts tatsächlich spüren wird. Allerdings gibt es noch einen anderen Aspekt: Jeder Code ist potenziell Code, der Schwachstellen haben oder durch Änderungen seitens Mozilla inkompatibel werden und vielleicht sogar Probleme bereiten kann. Auch von der Code-Pflege her ist es einfacher, keinen Code mitzuschleppen, der nicht benötigt wird. Ich würde Anpassungen immer auf das absolute Minimum reduzieren, um so wenig wie möglich von dem abzuweichen, was Mozilla ausliefert.
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.
Es gibt noch eine weitere Möglichkeit, wenn man wie in diesem Fall eine Funktion aufruft.
Statt:
toolbaritem.addEventListener('click', () => { onCommand() });Kann man auch einfach das hier schreiben:
toolbaritem.addEventListener('click', onCommand);Also eigentlich sollte es dadurch leichter lesbar werden, weil das &-Symbol dann nur noch verwendet wird, wo wirklich etwas verknüpft wird, und man nicht mehr durch überflüssige Zeichen irritiert werden kann und sich dann auch nicht mehr die Frage stellen muss, ob ein Leerzeichen versehentlich dazwischen gerutscht ist oder fehlt. Dazu kommt, dass man im Mozilla-Code auch nur diese Schreibweise findet. Dass verschachtelt wird, wird ja bereits durch die Einrückung klar. Und sowohl im Code-Editor als auch bei uns im Forum durch die Farben des Syntax-Highlightings.
Ein neuer Artikel wurde veröffentlicht:
Artikel lesen: „Mozilla veröffentlicht Firefox Klar 134 für Apple iOS“
Alles gut. Ich habe den Beitrag in dein vorheriges Thema verschoben. Schön, dass du dein Problem lösen konntest.
Im Startbeitrag stand nichts davon, was du suchst. Die Oberfläche zu vergleichen, ergibt nicht viel Sinn. Desktop- und Smartphone-Browser sind unterschiedliche Produkte für ganz unterschiedliche Geräteklasse. Nutzererwartungen, Bedienkonzepte etc. unterscheiden sich teilweise grundlegend. Daher ja auch meine Frage, um was konkret es dir geht. Denn wie gesagt gibt es einiges auch für Android, aber eben nicht alles und schon gar nicht mit der gleichen Oberfläche.
Wenn es um dir tatsächlich um eine Auflistung aller Medien ging, was mein einziges Beispiel war, was auf Android nicht zugänglich ist, was ist der konkrete Anwendungsfall, den du lösen möchtest?
Dein Script haut bei mir gleich mehrere Fehler raus:
CodeUncaught 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
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.
Zum Script kann ich nichts sagen, mir ist nur eine Sache beim CSS aufgefallen:
/* Symbol für den UserCSSLoader, eigentlich ein Menü */
#usercssloader-menu {
background-image: url("./images/CSS.png") !important;
background-position: center !important;
background-repeat: no-repeat !important;
background-size: 16px !important;
& > :is(.menu-accel-container,.menu-right) { display: none !important }
& > .menu-text[value="CSS"] { opacity: 0 !important }
}
/* Check mark (x) für den UserCSSLoader */
#usercssloader-menu menuitem[checked="false"] {
&::before {
content: "\274C";
display: block;
width: 16px;
height: 16px;
}
& .menu-iconic-text { padding-inline-start: 8px !important }
}Das & kann in den Zeilen 7, 8 und 19 entfernt werden. Grundsätzlich kann es immer am Anfang einer Zeile weggelassen werden, wenn direkt danach ein Leerzeichen folgt. Das war in der nicht finalen Spezifikation mal notwendig, aber glücklicherweise ist es am Ende nicht tatsächlich notwendig geworden. Das ergibt sich ja durch die Verschachtelung automatisch, dass sich das auf die Ebene darüber bezieht. Und so ist dieses Zeichen nur notwendig, um einen einzelnen Selektor näher zu definieren, wie hier in Zeile 13, weil ::before direkt und ohne Leerzeichen dazwischen an den Selektor eine Ebene darüber kommt.
Dafür braucht man kein Studium. Du musst vor allem ja nur die Scripts teilen, die bei dir die Fehler auslösen, und dazu schreiben, was die Fehlermeldung des jeweiligen Scripts ist. Idealerweise mit Zeilennummer, die auch immer dabei steht. Und dann kann jemand anderes schauen, was das Problem ist.
Speravir Ach herjeh, da beziehst Du Dich aber auf eine Version, die längst überholt ist.
„Längst überholt“ muss nicht sein. Von Alice gibt es eine Version für Firefox 135+, das ist sehr aktuell.
Was machen wir nun?
Die Scripts in der fehlerhaften Version zeigen, die dazugehörigen Fehler benennen und korrigieren lassen.
Hallo,
Anpassungen in der Datei userChrome.css haben nichts mit der Website-Darstellung zu tun.
Für mich sieht das eher nach einer Kombination von nicht sehr breitem Bildschirm und Zoom aus. Denn die Schrift sieht für mich größer aus, als sie normalerweise angezeigt wird. Firefox zeigt zwar eine Zoom-Stufe von 100 Prozent an, aber es spielen auch noch andere Faktoren mit hinein, wie die Skalierungs-Einstellungen von Windows oder layout.css.devPixelsPerPx in about:config. Ich sehe bei mir auch keinen Unterschied im Vergleich mit älteren Firefox-Versionen oder Chrome.
PS: Bitte benenne immer einen Link, im ersten Fall wäre das https://www.acer.com/at-de/support/…G.001/downloads. Das von Hand ablesen und eintippen zu müssen, ist unnötig mühsam.
Schema F:
menuitem.setAttribute("oncommand", "navigator.clipboard.writeText(gContextMenu.linkTextStr);");=>
menuitem.addEventListener('command', () => {
navigator.clipboard.writeText(gContextMenu.linkTextStr)
});Den Fehler hast du behoben, aber grisu2099 fragte nach der Prüfung, ob es bereits eine existierende Datei gibt, was du bemängelt hattest. Wenn ich mir den Code-Unterschied anzeige, wurde in diese Richtung nichts geändert.
Zwei Verbesserungsvorschläge, wo ich sie gerade sehe:
1. Cu.import('resource://gre/modules/Services.jsm'); gehört entfernt. Das war vorher auskommentiert, in der neuen Version wird das wieder ausgeführt. Die Datei gibt es nicht, entsprechend löst diese Zeile einen Fehler aus, wenn sie ausgeführt wird. In dem Fall kommt es doch nicht dazu, da vorher geprüft wird, ob Services definiert ist, und das ist immer der Fall. Aber dann kann man es auch gleich weglassen.
2. Ich sehe hier immer wieder (nicht nur in diesem Script) Vergleiche mit ==. Nach Möglichkeit sollte immer === verwendet werden. Das ist der striktere Vergleich und kann damit Fehler vermeiden, die entstehen können, wenn eine Seite des Vergleichs einen unerwarteten Typ hat. Außerdem ist === schneller. Es gibt nur Ausnahmesituationen, in denen == gebraucht wird.
Die Fehler, die Sören sah, erhalte ich nicht (ich hab das Skript direkt von Alice bezogen und die Texte übersetzt bzw. aus der Vorgängerversion übernommen).
Dann ist das ja logisch. Ich hatte mich auf das Script in der Version bezogen, die hier im Forum geteilt wurde. Ich schrieb ja sogar, dass das Originalscript den einen Fehler nicht hat. Zum anderen Fehler schrieb ich nichts, aber der ist dort ebenso nicht vorhanden.
Du hast ja schon geschrieben, dass deine Authenticator-App Firefox nicht kennt, daher wird das nicht klappen.
