Wenn ich die Pfade so angebe, wie Du vorgeschlagen hast, funktioniert es bei mir nicht!
Was mich wundert. Entsprechend Deiner Beschreibung hätte das
/* Datei */
#file-menu::before { background: url("./icons/mail-inbox-all.svg")!important; }funktionieren müssen. Hmmm, mysteriös.
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? 
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:
chrome
|
|-CSS
| |-contextMenu.css
|
|-icons
| |-mail-inbox.all.svg
|
|-userChrome.cssDann hättest Du in contextMenu.css das einzutragen:
/* 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
#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.
${scrollerProfileDirectory}
Wow, daran hab ich selbst nicht gedacht. Für alle: siehe unter Template literals (Template strings) (MDN).
Das lässt sich auch prima testen, weil man das genau so einfach in die Browserkonsole eingeben kann und dann sofort das Ergebnis sieht.
Ach, stimmt ja, hab ich gar nicht dran gedacht.
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?
PathUtils.toFileURI(PathUtils.join(PathUtils.profileDir, 'chrome', 'icons', 'websites'));Ich würde alternativ noch Folgendes vorschlagen:
#viewSidebarMenuMenu + menuseparator {
display: none !important;
}Das Pluszeichen ist der Nachbarselektor (SelfHTML; siehe dort auch den internen Link unter „Siehe auch“).
(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):
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:
// external-link-button.uc.js
/*
* Speravir, https://www.camp-firefox.de/forum/thema/135807/
* basiert auf Aris-t2, about_button.uc.js,
* https://github.com/Aris-t2/CustomJSforFx/blob/4111b9769ca005adf4dd710b7ed15c154949a3fd/scripts/about_button.uc.js
* und Aris-t2 in https://github.com/Aris-t2/CustomJSforFx/discussions/60#discussioncomment-4493915
*/
(function() {
if (!window.gBrowser) return;
const ProfilePath = PathUtils.toFileURI(PathUtils.join(PathUtils.profileDir, 'chrome'));
// Konfiguration
const Link = "https://addons.mozilla.org/",
Button_ID = "AMO-Button",
Label = "AMO",
Tooltiptext = "Link zu AMO (addons.mozilla.org)",
IconPath = "scriptimages/amo.png", // Pfad muss im ProfilePath liegen, Notation ohne Schrägstrich zu Beginn
MoreCSS = "";// zusätzliche CSS-Deklarationen, mit Semikolon innerhalb der Anführungszeichen abschließen
// Ende Konfiguration
const CSS = "list-style-image: url('" + ProfilePath + IconPath + "');" + MoreCSS;
// stattdessen mit vollständigem Pfad zu zentraler Dateiablage, hier unter C:\Users\Public:
//const CSS = "list-style-image: url('file:///C:/Users/Public/Pictures/Icons/amo.png');" + MoreCSS;
// oder mit Data-URI
//const CSS = "list-style-image: url('data:image/png;base64,DURCH-BASE64-CODE-ERSETZEN');" + MoreCSS;
try {
CustomizableUI.createWidget({
id: Button_ID,
type: 'custom',
defaultArea: CustomizableUI.AREA_NAVBAR,
onBuild: function(aDocument) {
let toolbaritem = aDocument.createElementNS("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul", "toolbarbutton");
let props = {
id: Button_ID,
class: "toolbarbutton-1 chromeclass-toolbar-additional",
label: Label,
tooltiptext: Tooltiptext,
style: CSS,
onclick: "if (event.button == 0) { openTrustedLinkIn('"+Link+"', 'tab'); };"
};
for (let p in props)
toolbaritem.setAttribute(p, props[p]);
return toolbaritem;
}
});
} catch(e) { };
})();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:
Unabhängig davon hat der Konfigurationsbereich mit Variablen oder Konstanten meiner Meinung nach noch weitere Vorteile:
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.
Kurz eingeworfen: Ich würde dazu die CSS-Eigenschaft text-shadow nutzen. Siehe text-shadow bei MDN und/oder text-shadow bei SelfHTML.
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.
Beides spricht bei mir nur Extension Buttons an,
Ja, mir ist inzwischen auch aufgefallen, dass sogar browsereigene Buttons wie der zum Anzeigen der Seitenleiste dieses zusätzliche toolbaritem nicht bekommen hat. Bei den Buttons, die man per Userskript einfügt, ist es allerdings kein Wunder, denn das müsste im Skript geändert werden.
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.
Ich habe bemerkt, dass Cookie AutoDelete so erweitert wurde, dass es ebenfalls mehr als die reinen Cookies behandeln kann. Das wäre dann auch einen Test wert.
Falls das das Problem des Originalposters war: Das Addon lässt den Firefox schon mal deutlich schneller starten.
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:
/* 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.
CAD konnte schon immer mehr als nur Cookies. Wo ich nicht sicher war - "Storage", das scheint wieder zu funktionieren.
Als ich es mir vor langer Zeit angesehen hatte, konnte es das eben nicht. Mag sein, dass es zu dieser Zeit defekt war, kann ich nicht mehr sagen.
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 beherrschen – Suchergebnisse 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.
Bis vor kurzem habe ich noch den "Vergiss Mein Nicht" benutzt.
Es hat sich jedoch herausgestellt, das diese Erweiterung massive Probleme in meinem Firefox verursacht und daher mußte ich in abstellen.
Die da wären? Langsamer Start? Das kommt davon, dass das Addon beim Löschen entsprechend der vorgegebenen Regeln alles andere blockiert.
DenalB hat schon den Cookie Quick Manager genannt. Mir geht es da genauso: Ich mag, dass alles übersichtlich auf einer Seite zu finden ist. Wie DenaIB sagt, könnte der gleichfalls Cookies löschen, aber meines Wissens keinen Local Storage bzw. letzteren nur über das Kontextmenü im Leistensymbol, das heißt aber auch immer nur für die gerade aktive Webseite.
Ansonsten könntest Du dir noch den Cookiebro ansehen, der blockiert den Firefox beim Start aber ebenso.
Nachtrag 1 Tag später: Ich habe bemerkt, dass Cookie AutoDelete so erweitert wurde, dass es ebenfalls mehr als die reinen Cookies behandeln kann. Das wäre dann auch einen Test wert.
Bei dem Script von Aris
Aris hat das Skript gerade aktualisiert, und zwar genau im CSS-Teil. Damit ist auch dieses hier hinfällig:
wobei zu beachten ist, dass am Ende jeder Zeile immer ein Backlslash („\“) stehen muss.
Der CSS-Bereich beginnt jetzt ab Zeile 100.
