Du hast die Quelle selbst verlinkt.
Upps, 
(eigentlich hätte ich lieber das nicht vorhandene Peinlich-berührt/Errötend-Smiley gesetzt). Das ist dann wieder mal so ein Fall von „Wer lesen kann …“
PS: Mir fällt gerade auf, dass das erste (
, a: (:|) und das fünfzehnte Smiley (, a: ||) in der Darstellung identisch sind, was, wie ich bei einem schnellen Blick in den Quelltext sehe, daran liegt, dass tatsächlich dasselbe Bildchen geladen wird. Das würde ich für einen Fehler halten.
ich möchte in meinem Still die Farbe für Texte, HTML, CSS, PHP, XML usw die Auskommatiert wurden generell eine andere Farbe verpassen.
Was bedeutet „usw.“? Willst du eigentlich für alle Sprachen die Kommentarfarbe ändern oder nur für die genannten und ein paar weitere?
Eigentlich ist es ja so gedacht, dass man unter Einstellungen > Stile konfigurieren Änderungen an den Farben vornimmt (und an der Schriftdarstellung, wenn gewollt), aber Du kannst innerhalb der XML-Datei nach den passenden Zeilen suchen. Als Beispiel HTML (ich hab hier die Standarddefinition kopiert):
<LexerType name="html" desc="HTML" ext="">
<WordsStyle name="DEFAULT" styleID="0" fgColor="000000" bgColor="FFFFFF" fontName="" fontStyle="1" fontSize="" />
<WordsStyle name="COMMENT" styleID="9" fgColor="008000" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" />
<WordsStyle name="NUMBER" styleID="5" fgColor="FF0000" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" />
<!-- gekürzt -->
</LexerType>Du könntest also in der gesamten Datei nach einer Zeile
<WordsStyle name="COMMENT" styleID="9" fgColor="008000" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" />suchen und die Farben ändern. Diese sind als Hexadezimalwerte eingetragen, jeweils RRGGBB. fgColor steht für die Textfarbe („foreground“), bgColor für den Hintergrund („background“), Standard für den Kommentar ist also Text in reinem Grün (Dezimalwert 128) ohne Rot- und Blauanteil (jeweils 00) vor weißem Hintergrund (alle drei Farbkanäle mit Maximalwert FF oder dezimal 255). Die Bezeichnung in name steht so auch im oben erwähnten Einstellungsdialog.
Nun besitzen manche Sprachen mehr als eine Kommentarvariante, zum Beispiel PHP:
<LexerType name="php" desc="PHP" ext="">
<!-- gekürzt -->
<WordsStyle name="COMMENT" styleID="124" fgColor="008000" bgColor="FEFCF5" fontName="" fontStyle="0" fontSize="" />
<WordsStyle name="COMMENT LINE" styleID="125" fgColor="008000" bgColor="FEFCF5" fontName="" fontStyle="0" fontSize="" />
<!-- gekürzt -->
</LexerType>Mir ist hier übrigens etwas aufgefallen: Deine Stildatei ist veraltet, denn bei dir finde ich unter PHP in Zeile 260 den Namen COMMENTLINE, also noch zusammen geschrieben. Das war wohl ein Fehler und ist vor einiger Zeit korrigiert worden (es gibt noch mehr solcher Korrekturen).
Es gibt auch Stile mit noch mehr Kommentarauszeichnungen, immer abhängig von der Sprache. Gleich die Definition für Actionscript, die erste Sprache in der Standard-Stildatei, enthält all das:
<LexerType name="actionscript" desc="ActionScript" ext="">
<!-- gekürzt -->
<WordsStyle name="COMMENT" styleID="1" fgColor="008000" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" />
<WordsStyle name="COMMENT LINE" styleID="2" fgColor="008000" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" />
<WordsStyle name="COMMENT DOC" styleID="3" fgColor="008080" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" />
<WordsStyle name="COMMENT LINE DOC" styleID="15" fgColor="008080" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" />
<WordsStyle name="COMMENT DOC KEYWORD" styleID="17" fgColor="008080" bgColor="FFFFFF" fontName="" fontStyle="1" fontSize="" />
<WordsStyle name="COMMENT DOC KEYWORD ERROR" styleID="18" fgColor="008080" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" />
<WordsStyle name="PREPROCESSOR COMMENT" styleID="23" fgColor="008000" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" />
<WordsStyle name="PREPROCESSOR COMMENT DOC" styleID="24" fgColor="008080" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" />
</LexerType>Das müsstest Du unter Umständen alles anpassen.
Das Add-on wurde laut Entwickler auf Grund eines DMCA Takedowns von AMO entfernt,
Nicht, dass ich das anzweifeln würde, aber hättest du eine Quelle dafür? Ich finde nur die Aussage des Entwicklers, dass das Addon (bzw. eigentlich ja zwei) ohne Hinweis/Ankündigung entfernt wurde, beispielsweise auf Twitter: Mitteilung des Entwicklers.
timios Siehe mal hier:
Sören, Du hast zweimal denselben Tippfehler in Deiner Ankündigung: Es muss about:third-party (Einzahl) heißen, wie man auch auf dem dazugehörigen Bildschirmfoto sehen kann.
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:
/* Vorlage: 2002Andreas in https://www.camp-firefox.de/forum/thema/135846/?postID=1217540#post1217540
*/
(function() {
if (!window.gBrowser) return;
/* Konfiguration */
const origID = "unified-extensions-button",// ID des originalen Buttons
label = "Erweiterungen",
tooltiptext = label;// auch eigener Text möglich, dieser in Anführungszeichen
/* Ende Konfiguration */
const menuButton = document.getElementById(origID),
buttonID = 'ucjs_' + origID;
if (!CustomizableUI.getPlacementOfWidget( buttonID )) {
try {
CustomizableUI.createWidget({
id: buttonID,
type: 'custom',
defaultArea: CustomizableUI.AREA_NAVBAR,
onBuild: function(aDocument) {
let toolbaritem = aDocument.createElementNS('http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul', 'toolbaritem');
toolbaritem.id = buttonID;
toolbaritem.className = 'chromeclass-toolbar-additional';
toolbaritem.setAttribute('label', label);
return toolbaritem;
}
});
if (!CustomizableUI.getPlacementOfWidget( buttonID )) {
menuButton.style.display = 'none';
return;
};
} catch(e) {
menuButton.style.display = 'none';
return;
};
};
setTimeout(function() {
document.getElementById(buttonID).appendChild(menuButton);
menuButton.setAttribute('consumeanchor', buttonID);
menuButton.setAttribute('label', label);
menuButton.setAttribute('tooltiptext', tooltiptext);
}, 0);
}());Firefox startet sehr langsam beim ersten mal.
Hast Du ein Addon, das Cookies löscht, in Benutzung? Dann könnte es daran liegen. Auf jeden Fall verlangsamen CookieBro und Vergiss Mein Nicht (Forget Me Not) den Start.
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.
