Beiträge von Speravir

    Auch wenn der Button mal wieder entfernt wird, hier noch eine Möglichkeit ihn per Skript zu verschieben:

    Auch von mir Danke dafür. Aber das ist Skriptcode, der hier schon für andere Buttons umhergeflogen ist, oder?

    Ich will das jedoch nutzen, um noch einmal dafür zu werben, die Skripte ein wenig anders zu schreiben:

    Unabhängig davon hat der Konfigurationsbereich mit Variablen oder Konstanten meiner Meinung nach noch weitere Vorteile:

    • Alles, was für jedes Skript individuell zu ändern ist, steht in einem Block sehr weit vorn.
    • Allein die Button-ID wird immer mindestens zweimal benötigt […], was ohne Variable/Konstante die Fehleranfälligkeit bei Änderungen erhöht.
    • Alles in allem weit geringerer Änderungsaufwand, […]

    … wenn man – wie ich ja vermute, auch hier – ein bestehendes Skript nur an ein anderes Symbol anpasst. Hier im Skript, wie es Andreas präsentiert hat, kommt die ID ucjs_unified-extensions-button sechsmal vor. Und wenn man wie hier die Original-ID immer nur um ucjs_ erweitert, dann kann man das sogar so umformen:

    Wenn es funktioniert, ist alles gut, aber:

    Ich habe den CSS-Code der Sympole.css nun in ein JavaScript "überführt", da bei mir nur absolute Pfadangaben funktionierten.

    Sympole.css? 8o


    Relative Pfade sind möglich, dann aber ohne file:///, siehe in url() - CSS (MDN). Man sieht übrigens auch, dass man sogar die Anführungszeichen weglassen darf (was ich nicht mag).


    Lass mich das mal anhand Deines Beispiels veranschaulichen:

    url("file:///C:/Users/Miras/AppData/Roaming/Mozilla/Firefox/Profiles/iff60u96.default-release/chrome/icons/mail-inbox-all.svg")

    Du hast im Chrome-Verzeichnis also einen Unterordner icons, aber natürlich auch die userChrome.css. Ich weiß es nicht, aber lass mich annehmen, dass Du Stile, die Du in der userChrome.css importierst, in einem Unterordner CSS ablegst, darunter eine contextMenu.css:

    Code
    chrome
      |
      |-CSS
      |  |-contextMenu.css
      |
      |-icons
      |  |-mail-inbox.all.svg
      |
      |-userChrome.css


    Dann hättest Du in contextMenu.css das einzutragen:

    CSS
    /* Datei  */
    #file-menu::before { background: url("../icons/mail-inbox-all.svg") !important; }

    Der Pfad ist also relativ zu dieser Stildatei anzugeben! Solltest Du unter CSS weitere Unterordner haben, dann wäre in einer darin liegenden Stildatei ein weiteres ../ vorn anzufügen.


    Würdest Du die Regel direkt in die userChrome.css einfügen, wäre

    CSS
    #file-menu::before { background: url("icons/mail-inbox-all.svg") !important; }
    
    /* oder: */
    
    #file-menu::before { background: url("./icons/mail-inbox-all.svg") !important; }

    zu schreiben. Letzteres soll in einigen Linux-Versionen besser funktionieren oder geschieht dort aus Gewohnheit.


    Nebenbemerkung: Wenn ich nur ein Hintergrundbild einfüge oder ändere, dann bevorzuge ich, die dafür vorgesehene Eigenschaft background-image zu nutzen, denn mit background werden implizit alle nicht aufgeführten Eigenschaften auf ihren Initialwert gesetzt, was ich vielleicht nicht will.

    osfile.jsm wird aus Firefox verschwinden.

    Dann auch noch einmal hier: Danke, Sören!


    Das Auslesen des eigenen Profile-Directory und das Zusammenfügen mit einem Unterordner/Dateinamen wird doch eigentlich schon seit Längerem so gehandhabt. z.B. auch in der 'userChromeShadow.uc.js':

    Hmmpf, stimmt. Ist mir leider nicht aufgefallen, weil ich es bisher nicht benötigt habe.


    OK, ist etwas kürzerer Code.

    Ich hab mich dafür entschieden, das aufzuteilen, weil ich das für etwas verständlicher halte.


    denn das Ergebnis der PathUtils-Methode endet bereits mit einem „/“ (vorausgesetzt es handelt sich um einen bereits existierenden Ordner, was in diesem Fall sicherlich zutrifft).

    Aah, wichtige Info. Bei der überholten Methode muss man ihn zu Beginn einfügen.


    PathUtils.toFileURI(PathUtils.join(PathUtils.profileDir, 'chrome', 'icons'));

    Und wenn ich ein weiteres Unterunterverzeichnis einbinden wollte, wird das als weiterer String hinten angehängt, also wie folgend?

    JavaScript
    PathUtils.toFileURI(PathUtils.join(PathUtils.profileDir, 'chrome', 'icons', 'websites'));

    (Entsprechend der Hinweise in unten folgenden Antworten überarbeitet.)

    Symbole in Skripten werden bisher, soweit ich es bemerkt habe, entweder mit Absolutpfaden angegeben oder als Data-URI mit Base64-kodiertem Inhalt.


    Ich hatte nun eine Idee und bei Aris nachgefragt, ob man es umsetzen könne, dass ein Skript seinen eigenen Pfad erkennt, so dass man dann Symbole aus auch einem relativ verlinkten Verzeichnis unterhalb dieses Skriptpfads auslesen könnte – und in der Tat, man kann (dem folgte die zuerst hier präsentierte, inzwischen überarbeitete Version).


    Man fügt in die userChrome.js oder jedes einzelne Schaltflächenskript ganz zu Beginn diese Zeile ein (Konstantenname ziemlich egal):

    JavaScript
    const ProfilePath = PathUtils.toFileURI(PathUtils.join(PathUtils.profileDir, 'chrome'));


    Und das kann man dann weiterverwenden. Ich gebe mal ein Beispiel, bei mir als website_mozilla-addons.uc.js gespeichert, Anmerkungen nach dem Skript:

    Die Datei muss wie üblich in UTF-8 abgespeichert werden; ich hatte das selbst zunächst nicht berücksichtigt und nach dem nicht vorhandenen Fehler im Skript gesucht (beachte in den Kommentaren die Umlaute, die kein ASCII sind).


    Ich habe also zusätzlich noch einen Parameter IconPath (als Konstante) angelegt und darin einen Pfad zu einer Datei; wie im Kommentar nachzulesen, muss sich dieser Pfad zur Bilddatei innerhalb des Profils befinden. Wie Sören unten in Beitrag #9 gezeigt hat, könnte man auch direkt das Unterverzeichnis in ProfilePath registrieren (oder sogar weitere Unterunterverzeichnisse, siehe meine Frage in Beitrag #11 und Sörens folgende Antwort), die Variante in meinem Beispiel bietet aber etwas mehr Variabilität.


    Innerhalb von const CSS werden dann beide Konstanten genutzt. Statt " + ProfilePath + IconPath + " könnte man aber auch weiterhin einen Absolutpfad – das kann auch ein chrome-URI für ein mit dem Firefox ausgeliefertes Symbol sein – oder einen Data-URI eintragen. MoreCSS ist vor allem sinnvoll für CSS-Filter oder zusätzliche Umrandungen oder einen anderen Hintergrund pro Symbol.


    Vorteile:

    • Man spart sich die Base64-Kodierung.
    • Wenn ich mich nicht irre, verringert das Laden einer Bilddatei den Speicherbedarf.
    • Man muss keine Absolutpfade angeben und die Bilddateien befinden sich direkt im Profil, was zusammen die Portabilität erhöht (Testprofile, Sicherungen).


    Unabhängig davon hat der Konfigurationsbereich mit Variablen oder Konstanten meiner Meinung nach noch weitere Vorteile:

    • Alles, was für jedes Skript individuell zu ändern ist, steht in einem Block sehr weit vorn.
    • Allein die Button-ID wird immer mindestens zweimal benötigt (im AnimationToggleButton-Skript immerhin achtmal), was ohne Variable/Konstante die Fehleranfälligkeit bei Änderungen erhöht. Achtung: In einigen Skripten (das AnimationToggleButton-Skript ist ein Beispiel) gibt es einen Bereich mit einer OnClick- oder OnCommand-Funktion, wo die ID weiterhin explizit eingetragen werden muss (wobei man es auf einmal optimieren kann), weil dieser Teil so wie eingetragen in das Browser-DOM eingefügt wird.
    • Alles in allem weit geringerer Änderungsaufwand, auch wegen des Wegfalls der Base64-Kodierung.


    Wenn es um externe Webseiten geht, besteht das größte Problem nun nur noch darin, das Seitensymbol (Favicon) herunterzuladen und unter Umständen in ein kleineres Format zu konvertieren (in meinem Beispiel amo.png: ).

    Aber sollte man viele Codes nutzen, dann ist es übersichtlicher, als alles in der userChrome.css zu haben.

    Das ist richtig und handhabe ich selbst genauso (wenn auch nicht sooo kleinteilig, wie von Mira_Belle vorgeschlagen), aber, ähm, um @import geht es mir doch gar nicht.

    Geht auch ganz einfach mit den Browser-Werkzeugen.

    Stimmt auch, ich wollte nur auf die weiteren Möglichkeiten hinweisen, gerade, wenn man eine Deklaration erst mal austesten will.

    ;)

    Die shadow.css sollte dann so aussehen:

    CSS
    @-moz-document url(chrome://browser/content/browser.xhtml) {
      /* … */
    }

    Das ist nicht notwendig. Es heißt ja nicht umsonst userChrome.css.

    Spiel etwas mit den Werten herum und Du wirst sehen was passiert.

    Denke aber daran, nach jeder Änderung musst Du den Firefox neu starten!

    Sowohl bei MDN als auch Selfhtml kann man übrigens rumspielen, ohne abzuspeichern, auch mit zusätzlichen Deklarationen für Hintergrund- und Textfarbe.

    Ich beziehe mich auf diesen Satz,

    Ich mich auch, aber ich bemerke erst jetzt, dass ich mich missverständlich ausgedrückt habe: Ich meinte damit „CAD lässt den Firefox schneller starten, als wenn eines der beiden anderen erwähnten Addons aktiv ist.“ Du hast Recht, dass immer noch eine Verzögerung im Vergleich mit Firefox ohne cookielöschendes Addon vorhanden ist.

    Kann ich mir nicht wirklich vorstellen, weil diese Erweiterung diverse Aufgaben erst beim Start ausführt.

    Ob Du dir das vorstellen kannst, ist unerheblich. Ich habe das Verhalten beschrieben, wie es bei mir auftritt. Ich glaube auch, dass Du vergisst, dass (soweit ich das sehe) ForgetMeNot (VergissMeinNicht) und CookieBro nur beim Neustart alte Cookies und andere Daten löschen, während CAD das zwar auch macht, aber standardmäßig vieles bereits beim Domainwechsel erledigt.

    Leider weiss ich nicht, wie ich toolbaritem einbinden kann.

    Ein Ansatz wäre, toolbaritem statt toolbarbutton in die Regel zu setzen. Aber ich wollte nur auf diesen neuen Umstand hinweisen. Ich schrieb doch, dass ich mir die Stile nicht näher angesehen habe.


    Alternativ nimmt man einen Klassennamen (toolbaritem könnte zu allgemein sein), wie es visoer gemacht hat:

    #nav-bar .toolbaritem-combined-buttons.unified-extensions-item.chromeclass-toolbar-additional {

    Eine Klasse sollte aber völlig ausreichen. Bei mir sieht es so aus:

    CSS
    /* Symbole enger zusammen */
    #nav-bar .toolbaritem-combined-buttons {
      margin-inline: -2px !important;
    }

    Das ist ein Abwandlung der Originalregel, die auf alle Toolbars wirkt und einen zusätzlichen Abstand von 2px vorschreibt.

    Ohne mir die Stile oben im Detail anzusehen, ein Hinweis: In Firefox 108 wurden die toolbarbuttons, und damit deren innere Elemente eine Ebene nach unten verschoben. Es wurde noch ein toolbaritem um sie herum gepackt. Das Toolbaritem hat nun die ID bekommen, die vorher der Button besaß. Auf die Buttons von Userskripten trifft das aber nicht zu, wenigstens so lange nicht, bis jemand an einem solche Skript eine Änderung vornimmt. Bei mir gab es nämlich auch plötzlich eine Änderung im Abstand zwischen den Symbolen; so habe ich es überhaupt bemerkt.

    Es gibt ja standardmäßig eine Seitenleiste im Firefox (mit Symbol, das man sich links oder rechts in die Tableiste legen kann). Die wird für verschiedene Sachen genutzt, einfach mal Strg+B drücken oder Strg+H (wenn man nicht gerade mit dem Fokus hier im Editor ist ;) ). Es gibt nun mehrere Addons, die die Tabfunktionalität in diese Seitenleiste integrieren. Ob sie dann mit angehefteten (pinned) Tabs umgehen können, müsste man ausprobieren. Es gibt aber auch Addons für vertikal angeordnete Tabs außerhalb der Seitenleiste, da müsste man dann auch mal ausprobieren, ob diese pinned Tabs beherrschenSuchergebnisse für „vertical“ bei AMO.


    spockilein weißt Du schon, wie man Testprofile anlegt und wieder löscht?


    Ich habe eben selbst nach vertical pinned tabs firefox gesucht und dabei das hier gefunden: Vertical tabs for Firefox, inspired by Edge, mit vielversprechenden Screenshots. Ich befürchte aber, dass das einen Firefox-Neuling zu sehr überfordert. Oh und dann gibt es
    noch VerticalTabs, wo man sich das HoverLayout genauer ansehen sollte (beachte Erläuterungen in den Unterverzeichnissen). Und wenn man weitersucht, findet man noch mehr. Hier ist eine Seite, die 5 Addons für vertikale Tabs empfiehlt (teils in, teils außerhalb der Seitenleiste) Best Vertical Tabs extensions for Firefox; dabei sind auch die Addons, auf denen die beiden eben verlinkten Lösungen basieren. Wie gesagt, man muss immer erst testen, ob es möglich ist, die Tabs auf ihre Symbole/Favicons zu reduzieren.

    Edit: Teile durchgestrichen – in Tests fügen sich alle Addons in die Seitenleiste ein. Ich hab da also entweder etwas missverstanden oder es mit Userskripten verwechselt; die gibt’s nämlich auch noch.