Für die Dateipfade zu den Icons besser so etwas nutzen!
Es ist da auch schon ein Fallback "eingebaut" falls irgendetwas klemmt.
Danke!
Ich Schlaumeier hab mein einziges Script mit diesem Dateipfad - der bei mir am Mac nichtmal geht - als Beispiel benutzt, und dann auch noch FuchsFan deswegen angemeckert...
Nicht bei mir
Stimmt, das habe ich nicht in der richtigen Reihenfolge gemacht.
Dann habe ich dieses noch, ist im Aufbau fast deinem ähnlich. Kannst ja mal probieren.
Dankeschön, aber gleiches Spiel; sowohl Problem #1 als auch #2.
Und noch eine Kleinigkeit: die Dateipfade für die Icons url("file:///C:/... funktionieren vermutlich auf Windows, aber nicht hier am Mac, also nicht perfekt für Kompatibilität.
Nicht bei mir, Problem #1, wie beschrieben.
Erstes Fenster A schliessen, dann in Fenster B probieren.ist damit gleichzeitig auch dieses Problem gelöst?
An Deinem Smily sehe ich, dass Du die Antwort schon kennst. Das war aber auch nicht das Thema in dieser Kommunikation.
Nein, an dem Grübel Smiley siehst du dass ich die Antwort nicht kannte, daher die Frage.
Ich weiss immer noch nicht was das Script machen soll, also auch nicht wie ich es selber testen könnte.
Das Thema ist aber sehr wohl die allgemeine, nicht eingeschränkte Nutzbarkeit, egal mit welcher Lösung, worauf sich dein Beitrag bezog - inklusive zitiertem Text zu eben der von mir nachgefragten Problematik.
Du hast selber beides verbunden. 
Aber Semantik und Empfindlichkeiten beiseite, die Fragestellung hört sich interessant an, aber was ist sie eigentlich?
Ist es sowas: der Button soll für alle geöffneten Fenstern das gleiche bewirken, egal in welchem Fenster er aktiviert wird, und idealerweise dann auch noch bei: Problem #1, wie beschrieben. Erstes Fenster A schliessen, dann in Fenster B probieren.?
Falls ja, ich habe Buttons die genauso funktionieren, und die benutzen das gleiche Prinzip wie das von Speravir in #4443, aber mit anderen und einfacheren Funktionen.
Dadurch, dass man mit Hilfe des Skriptes eine Einstellung im Firefox ändert, die im gesamten Profil gültig ist, lässt sich letzteres meines Wissens nach nicht verhindern.
Kleine Anmerkung:
Das Script aus RE: userChrome.js Scripte für den Fuchs (Diskussion) funktioniert wie erwartet (Änderung der Animation sowie des Icons ausschließlich im aktiven Fenster).
Nur aus Neugierde, ist damit gleichzeitig auch dieses Problem gelöst?
funktionstüchtig in allen Fenstern
Nicht bei mir, Problem #1, wie beschrieben.
Erstes Fenster A schliessen, dann in Fenster B probieren.
Es gibt hier eine Menge Scripts für Buttons, die nach einem ähnlichen Schema aufgebaut sind, siehe Beispiel unten.
Wiederkehrende Probleme mit vielen davon sind Folgendes:
#1:
- Firefox öffnen, das Programm öffnet mit einem Browser Fenster (Fenster A).
- Script Button funktioniert; jetzt neues Fenster B öffnen, dann das Fenster A - das erste beim Start geöffnete Fenster - schliessen.
- Script Button funktioniert nicht mehr in Fenster B oder anderen Fenstern, sobald Fenster A geschlossen wurde.
#2:
- Firefox öffnen, das Programm öffnet mit einem Browser Fenster (Fenster A).
- Script Button funktioniert; jetzt neues Fenster B öffnen, dann den Button in Fenster B klicken.
- Button führt das Script aus - aber in Fenster A, nicht im aktiven Fenster B.
Dazu eine kleine Linksammlung, mehr oder weniger relevant:
Die problematischen Scripts benutzen Fix #1, vorgeschlagene Lösung (Fix #2), hier als Code Beispiel:
// aboutconfig-button.uc.js Test #3
(function() {
if (location != 'chrome://browser/content/browser.xhtml') return;
try {
CustomizableUI.createWidget({
id: 'aboutconfig_button',
type: 'custom',
defaultArea: CustomizableUI.AREA_NAVBAR,
onBuild: function(aDocument) {
let currentProfileDirectory = Services.dirsvc.get("ProfD", Ci.nsIFile).path.replace(/\\/g, "/");
let buttonicon = "LettersC-1.png"
let toolbaritem = aDocument.createElementNS('http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul', 'toolbarbutton');
var props = {
id: 'aboutconfig_button',
class: 'toolbarbutton-1 chromeclass-toolbar-additional',
label: 'About:Config',
tooltiptext: 'About:Config',
style: 'list-style-image: url("' + ("file:" + currentProfileDirectory + "/chrome/icons/" + buttonicon) + '");'
// alte Version obsolet
//onclick: 'if (event.button == 0) { \
// openTrustedLinkIn("about:config", "tab");\
// }; '
// alte Version Ende
};
for (var p in props)
toolbaritem.setAttribute(p, props[p]);
// Fix #1
// toolbaritem.addEventListener('click', event => {
// if (event.button == 0) {
// openTrustedLinkIn("about:config", "tab");
//}
//});
// Fix #1 Ende
return toolbaritem;
}
});
} catch(e) { };
// Fix #2
document.getElementById('aboutconfig_button').addEventListener('click', event => {
if (event.button === 0) {
openTrustedLinkIn("about:config", "tab");
}
});
// Fix #2 Ende
})();Warum?
Es ist nur ein minimaler Unterschied zwischen den beiden Varianten, und gleich einfach umzusetzen, also warum nicht die bessere Variante benutzen?
Bei mir am Mac ist es sehr auffällig, weil hier Firefox nicht beendet wird beim Schliessen aller Fenster, also habe ich oft eine aktive, aber fensterlose Fx App im Dock; ich vermute sehr viele User stolpern eventuell mal über das Problem, ohne es zu melden oder nachvollziehen zu können.
Nicht zu vergessen dass mehrere Fenster sehr wohl benutzt werden, gerade auch in einem Setup mit mehr als einem Monitor; in dem Fall kann es ganz schnell Ärger geben mit einem Script das nicht alle Fenster - wie im Einzelfall gewünscht - bedienen kann.Letztlich ist es aber auch einfach ein Fehler im Script.
Warum nicht?
Die Lösung kommt von einem Amateur (mir), und könnte unvorhergesehene, aber von mir noch nicht beobachtete Probleme verursachen.
Warum nicht nicht?
99,99% aller User, oder nur du selber, benutzen nie mehr als ein Browserfenster. Kein Argument für Code der publik gemacht wird. 
Ausserdem kommt Fix #1 aus der selben Quelle.
Wie schon gesagt, das Skript funktioniert, allerdings gefallen mir die Zeilenabstände nicht und dafür ist wohl Zeile 60-63 (inklusive der davor geöffneten { in Zeile 59) verantwortlich. Wenn ich den Teil lösche ist es so wie ich es haben möchte. Allerdings würde ich es statt löschen lieber auskommentieren, nur bin ich leider zu doof dazu das richtig hin zu bekommen. Kann mir das jemand sagen wie ich das korrekt mache?
So geht das; um den Code den du kommentieren willst /* und */ setzen.
Hmm, ich hab da mal weiter gegoogelt, und bin darauf gestossen.
Und das ganze habe ich mal - eher unelegant - in ein einfaches Script gewürgt.
Das erhoffte Ergebnis: die .zip Datei runterladen, das enthaltene Script und Ordner in den chrome Ordner packen, Restart mit Cache löschen, wie immer bei Script Installationen, und fertig.
Enthalten sind JS Script, CSS und Icon, keine Anpassungen nötig.
Benutztes Script:
//profile-button tester icons separates CSS
(function() {
if (location.href !== 'chrome://browser/content/browser.xhtml')
return;
try {
CustomizableUI.createWidget({
id: 'Profiles_button',
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: 'Profiles_button',
class: 'toolbarbutton-1 chromeclass-toolbar-additional',
label: 'Profiles',
tooltiptext: 'about:profiles',
};
for (var p in props)
toolbaritem.setAttribute(p, props[p]);
return toolbaritem;
}
});
} catch(e) { }
document.getElementById('Profiles_button').addEventListener('click', event => {
if (event.button === 0) {
openTrustedLinkIn("about:profiles", "tab");
}
});
// Create references to APIs we'll use
let ss = Cc["@mozilla.org/content/style-sheet-service;1"].getService(Ci.nsIStyleSheetService);
let io = Cc["@mozilla.org/network/io-service;1"].getService(Ci.nsIIOService);
let ds = Cc["@mozilla.org/file/directory_service;1"].getService(Ci.nsIProperties);
// Get the chrome directory in the current profile
let chromepath = ds.get("UChrm", Ci.nsIFile);
// Specific file: Subfolder / userChrome.css or userContent.css
chromepath.append("profilesbutton_style");
chromepath.append("profilesbutton_external.css");
// Morph to a file URI
let chromefile = io.newFileURI(chromepath);
// Load the sheet
ss.loadAndRegisterSheet(chromefile, ss.USER_SHEET);
})();Benutztes CSS:
#Profiles_button .toolbarbutton-icon {
list-style-image: url("icons/LettersP-1.png");
}Alles zusammen als Paket:
Und die CSS-Dateien werden dann via JavaScript geladen, ohne das Laden der gesamten Website zu verzögern. Das kombiniert alle Vorteile. So hat man weiter alle Vorteile externer CSS-Dateien, blockiert aber nicht den Rendering-Vorgang und muss gleichzeitig für das, was man sofort sieht, nicht auf das Laden der CSS-Dateien warten.
Hättest du dafür einen Tip, oder simple Lösung?
Ich hab schon gesucht, aber stosse da an meine Grenzen...
Sagen wir mal wir haben DasScript.us.js , was im Profil/chrome Ordner liegt, und eine extra CSS Datei DasScript.css, im gleichen Ordner.
Wüsstest du eine schlanke Lösung, idealerweise mit relativem Dateipfad, um die CSS Datei via das Script zu laden?
Ich dachte schon öfter an ein Paket mit JS Script, CSS Datei und Icon, das der User nur in den chrome Ordner kopieren muss, und es läuft sofort.
Man kann auch einfach über die userChrome.css das CSS importieren, aber dann müssen die User halt wieder anfangen im Code rumzuschreiben.
Alles anzeigenEin nicht öffentlicher Unterbereich?
Die Unterscheidung in Entwickler/Helfer und "normalem" Anwender halte ich für falsch. Keiner von uns ist wirklich überall zu Hause und jeder, der sich mit individuellen Anpassungen beschäftigt, tut das oft auch auf Code-Ebene und wenn es auch nur das Ändern des Farbcodes oder bestimmter Größenangaben bei einem CSS-Code oder Skript ist. Außerdem ist ein reiner Nutzer eines Skriptes ein sehr wichtiger Aspekt der Entwicklung, weil ja hier die Anforderungen definiert werden und das Skript letztendlich getestet wird.
Es muss, es soll ja auch nicht ein eigenes Unterforum sein, es kann ja auch ein Unterunterforum sein, halt extra nur für
einzelne Skripte und nicht so ein Durch einander wie bisher, dass in einem Thread dutzende Skript besprochen werden.Aber das haben wir doch schon und zwar in Form einer professionellen Versionsverwaltung, die genau für solche Dinge geschaffen wurde:
https://github.com/Endor8/userChrome.js
Es wäre aber vermutlich trotzdem hilfreich, sowas wie ein Coding Basics Subforum zu haben, für allgemeine und aktuell nötige Diskussionen zu generellen Lösungsansätzen, wie oben schon erwähnt.
Dem stimme ich zu, obwohl ich mir die Frage stelle, ob nicht jeweils ein eigener Thread für Lösungsansätze zu einem generellen Problem ausreichend ist?
Weil ja hier auch immer von Wiederverwertung und Standardisierung bestimmter Lösungen gesprochen wird:
- Einen privaten Bereich halte ich auch für kontraproduktiv, v.a. auch wegen der von dir erwähnten wichtigen User Kommentare zu Funktion, gewünschten Features und Nutzbarkeit.
Es sollte sich auch niemand bewerben müssen um in einen Sub beitragen zu können, va potentielle Experten die einsteigen wollen.
- Endor macht einen fantastischen Job, aber ein repository ist mE nicht Teil dieser Diskussion; dort werden Dateien bereitgestellt, nicht diskutiert. Wegen mir sollten die Einzelthemen zu spezifischen Scripts/CSS auch unbedingt im Anpassungsforum bleiben.
- Ein Anpassungen/Subforum hätte den einen Vorteil, die Threads zur Wiederverwertung und Standardisierung - exakt der Punkt - vom Anpassungsforum räumlich zu separieren, um solche Threads leichter überblicken zu können, ohne wie gesagt sie anzupinnen oder dass sie vom täglichen Themenflow hin und her geschoben zu werden.
Falls in der Form realisiert, könnte das schliesslich als knowledge base dienen; die Forensuche kannste einfach knicken dafür.
Fakt ist, dass für mich ein Grossteil der wichtigsten Infos und Entwicklungen hier im Forum mühsam zusammengesucht werden müssen, indem man jedes einzelne Topic nach möglichen Perlen durchkämmt.
Der Übeltäter war eine (in Worten: 1) bei der Überarbeitung meines CSS vergessene Zeile. Kaum ist die wieder eingefügt, spielt auch die Leiste wieder brav mit...
Ist das Script von #1 jetzt mit korrigierter CSS?
Und nur mal 2 Beispiele:
Diese schon öfters erwähnte Thread ist gepackt voll mit super Infos zu der addEventListener Geschichte, aber immens aufgebläht durch die Einzelscript Diskussionen.
Hier haben wir wichtige Infos zu eval etc., die in einem Script spezifischen Thread versteckt sind.
Das sind für mich 2 typische Beispiele: Die Themen wurden erstellt, weil Skripte nach Firefox-Updates nicht mehr funktionierten. Das ist nach meiner Beobachtung die Regel. Im Verlauf der Diskussion wurden die nötigen Änderungen herausgefunden und in die Skripte integriert. Dass in dem Thema auch für die folgenden Firefox-Versionen grundsätzliche Informationen stehen, weiß man beim Erstellen des Themas noch nicht. Um solche Themen übersichtlich in einem Unterforum darzustellen, müsste also ein Moderator die Themen durchforsten und dann umbenennen und - oft nur zum Teil - verschieben. Und nach diversen Firefox-Updates ist manches schon wieder anders.
Die weniger aufwändige Möglichkeit, mit der Tendenz des Lebens zum Chaos umzugehen, ist wie bisher mit vertretbarem Zeitaufwand die Forensuche zu nutzen.
Mit einem bestehenden Unterforum könnte man die allgemeine Diskussion in Einzelthemen vermeiden, indem die relevanten Beiträge nicht dort, sondern bei bestehendem Bedarf als Thread in eben diesem Unterforum diskutiert werden.
Die Forensuche hilft nicht, wenn man über eine Problematik nichts erfahren hat - weil sie in Einzelthemen versteckt ist - was dann zu vielfach wiederholten gleichen Fragen in weiteren Einzelthemen führt, und unkoordinierten Antworten.
Die Forensuche leidet zudem darunter, dass nicht ausgeklappte Codes das Suchen sehr erschweren.
Moderatoren müssen keinen Extraaufwand betreiben wie von dir beschrieben, wenn eine Problematik in ihrem eigenen Thread diskutiert wird, das ist ja die Idee dahinter.
Bestehende Beiträge kann man ja immer noch als User zitieren und verlinken.
In den genannten Beispielen ist es mir und anderen recht schnell aufgefallen, dass das vorliegende Problem übergreifende Auswirkungen hat oder haben könnte.
Was wir als User machen müssten, wäre diese generellen Themen nicht in dem Ausgangsthema (wie hier) zu besprechen, sondern bei Bedarf zeitnah einen neuen Thread in dem Subforum erstellen, und von dort aus weiter zu arbeiten.
Das funktioniert durchaus in vielen Foren, muss man nur etablieren.
Ich bin da geteilter Meinung: zum einen ja zu einem Subforum rein für Basiskonzepte und -Lösungen, zum anderen häufen sich spezifische Anfragen oft nur wenn ein Fx Update grundlegende Probleme für bestehenden Code in JS oder CSS verursacht, was nicht immer der Fall ist.
Es wäre aber vermutlich trotzdem hilfreich, sowas wie ein Coding Basics Subforum zu haben, für allgemeine und aktuell nötige Diskussionen zu generellen Lösungsansätzen, wie oben schon erwähnt.
Viele dieser Ansätze gehen oft unter in, oder verteilen sich auf diverse Threads, und Themen anzupinnen hat ja auch seine Grenzen, wenn man das Anpassungen Forum nicht damit überfluten will.
Den zusätzlichen Aufwand für das einrichten und verwalten/moderieren eines zusätzlichen Subforums kann ich allerdings nicht einschätzen, das ist natürlich auch ein wichtiger Aspekt.
Und nur mal 2 Beispiele:
Diese schon öfters erwähnte Thread ist gepackt voll mit super Infos zu der addEventListener Geschichte, aber immens aufgebläht durch die Einzelscript Diskussionen.
Hier haben wir wichtige Infos zu eval etc., die in einem Script spezifischen Thread versteckt sind.
Für mich stellt sich bei dem Thema im Eigentlichen die Frage, wie man generell, als Skript Author, Icons am besten einbindet.
Generell, für diverse existierende Skript-Layouts(?), nicht für jedes einzelne Skript.
Das Ziel wäre mE den einfachen Zugang zur Benutzung von Skripts zu erhalten, indem man ein Basisicon in irgendeiner Form integriert, und auch eine einfache Lösung zur Benutzung eigener Icons bereitzustellen.
Wie schon erwähnt, momentan gibt es halt die base64 Icons
in vielen Scripts, oder die Dateipfad Varianten für die Nutzung von eigenen Icons.
Die Fallback Geschichte könnte ein Zwischending sein, das beide Eventualitäten bedient.
Wobei ich mich nach einigen Versuchen jetzt doch frage, ob man damit mit Kanonen auf Spatzen schiesst.
Ich habe die OT Beiträge mal verschoben nach:
Einbindung von Icons in Skripts
[…]
In diesem Fall denke ich, kaum jemand wird sich beide Skripte gleichzeitig installieren.
Zumindest wäre dieser Weg eine Lösung für weg von base64. Möchte dann jemand ein anderes Icon, dann kann er es ja austauschen, oder eben hier im Forum nachfragen wie er das machen müsste.
Dankeschön!
evtl. mal ran und verschieben.
Das kann ich machen wenn du mir sagst, ab welchem Beitrag und welchen Titel der Thread dann haben soll.
Mein Vorschlag, ab #48, dann geht kein Thread spezifischer Code verloren.
Titel könnte etwa sein: Einbindung von Icons in Skripts.
Wir sollten aber für DIESE Diskussion, so finde ich, ein eigenes Thema aufmachen, oder?
Das macht Sinn; da könnte 2002Andreas evtl. mal ran und verschieben.
Und, Test:
//profile-button.uc.js tester icons Mira 1b
(function() {
if (location.href !== 'chrome://browser/content/browser.xhtml')
return;
try {
CustomizableUI.createWidget({
id: 'Profiles_button',
type: 'custom',
defaultArea: CustomizableUI.AREA_NAVBAR,
onBuild: function(aDocument) {
//let currentProfileDirectory = Services.dirsvc.get("ProfD", Ci.nsIFile).path.replace(/\\/g, "/");
//let buttonicon = "LettersP-1.png";
let toolbaritem = aDocument.createElementNS('http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul', 'toolbarbutton');
let props = {
id: 'Profiles_button',
class: 'toolbarbutton-1 chromeclass-toolbar-additional',
label: 'Profiles',
tooltiptext: 'about:profiles',
//style: 'list-style-image: url("' + ("file:" + currentProfileDirectory + "/chrome/icons/" + buttonicon) + '");',
};
for (var p in props)
toolbaritem.setAttribute(p, props[p]);
return toolbaritem;
}
});
} catch(e) { }
document.getElementById('Profiles_button').addEventListener('click', event => {
if (event.button === 0) {
openTrustedLinkIn("about:profiles", "tab");
}
});
let currentProfileDirectory = Services.dirsvc.get("ProfD", Ci.nsIFile).path.replace(/\\/g, "/");
let buttonicon = "LettersP-1.png";
let img = new Image();
img.src = "file:" + currentProfileDirectory + "/chrome/icons/" + buttonicon;
img.onload = function() {
Profiles_button.style.listStyleImage = 'url("' + ("file:" + currentProfileDirectory + "/chrome/icons/" + buttonicon) + '")';
};
img.onerror = function() {
Profiles_button.style.listStyleImage = 'url("chrome://browser/skin/translations.svg")';
};
})();So, mit Fallback.
Als Muster für andere Skripte.JavaScript// ------------------------------------------------------------------------------------------------ // Pfad zum Profilordner let ProfilePath = Services.dirsvc.get("ProfD", Ci.nsIFile).path.replace(/\\/g, "/"); // Pfad in den entsprechenden Unterordner let IconPath = '/chrome/icons/'; // Pfad in den entsprechenden Unterordner // Name & Dateiendung des anzuzeigenden Symbols! let ButtonIcon = "Google.svg"; // Erstelle ein img-Element, um zu überprüfen, ob die Grafik geladen werden kann let img = new Image(); img.src = "file:" + ProfilePath + IconPath + ButtonIcon; img.onload = function() { // Wenn die Grafik geladen werden kann, setze das listStyleImage menuitem.style.listStyleImage = 'url("' + ("file:" + ProfilePath + IconPath + ButtonIcon) + '")'; }; img.onerror = function() { // Wenn die Grafik nicht geladen werden kann, verwende das Fallback-Icon menuitem.style.listStyleImage = 'url("chrome://browser/skin/translations.svg")'; }; // ------------------------------------------------------------------------------------------------
Mira, wenn wir dich nicht hätten, und die kleinen Kartoffeln - vielen Dank!
Kleiner Schönheitsfehler nur auf meiner Seite; das ist nur ein schneller erster Test, und dein Code etwas umgebaut um meinen existierenden Code nicht komplett anzupassen zu müssen - aber die Einbindung ist bei mir noch etwas grob.
Das alte Problem mit dem zweiten Fenster : ich muss den Code nach unten schieben, raus aus dem oberen Codeblock/Loop(?), und ein paar Variablen wiederholen, damit er auch im Elchtest funktioniert.
A propos, was ist eigentlich der Grund für den ganzen props Code, hier Zeile 29-39?
Kann man die Attribute nicht direkt einfügen?
Ich denke da kommt das Problem her.
Kein Drama, aber halt nicht sehr elegant:
//profile-button.uc.js tester icons Mira
(function() {
if (location.href !== 'chrome://browser/content/browser.xhtml')
return;
try {
CustomizableUI.createWidget({
id: 'Profiles_button',
type: 'custom',
defaultArea: CustomizableUI.AREA_NAVBAR,
onBuild: function(aDocument) {
let currentProfileDirectory = Services.dirsvc.get("ProfD", Ci.nsIFile).path.replace(/\\/g, "/");
let buttonicon = "LettersP-1.png";
// let img = new Image();
// img.src = "file:" + currentProfileDirectory + "/chrome/icons/" + buttonicon;
//
// img.onload = function() {
// toolbaritem.style.listStyleImage = 'url("' + ("file:" + currentProfileDirectory + "/chrome/icons/" + buttonicon) + '")';
// };
//
// img.onerror = function() {
// toolbaritem.style.listStyleImage = 'url("chrome://browser/skin/translations.svg")';
// };
let toolbaritem = aDocument.createElementNS('http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul', 'toolbarbutton');
let props = {
id: 'Profiles_button',
class: 'toolbarbutton-1 chromeclass-toolbar-additional',
label: 'Profiles',
tooltiptext: 'about:profiles',
style: 'list-style-image: url("' + ("file:" + currentProfileDirectory + "/chrome/icons/" + buttonicon) + '");',
};
for (var p in props)
toolbaritem.setAttribute(p, props[p]);
return toolbaritem;
}
});
} catch(e) { }
document.getElementById('Profiles_button').addEventListener('click', event => {
if (event.button === 0) {
openTrustedLinkIn("about:profiles", "tab");
}
});
let currentProfileDirectory = Services.dirsvc.get("ProfD", Ci.nsIFile).path.replace(/\\/g, "/");
let buttonicon = "LettersP-1.png";
let img = new Image();
img.src = "file:" + currentProfileDirectory + "/chrome/icons/" + buttonicon;
img.onload = function() {
document.getElementById('Profiles_button').style.listStyleImage = 'url("' + ("file:" + currentProfileDirectory + "/chrome/icons/" + buttonicon) + '")';
};
img.onerror = function() {
document.getElementById('Profiles_button').style.listStyleImage = 'url("chrome://browser/skin/translations.svg")';
};
})();Wie sowas, was aber auch kein Fortschritt ist zu meinem ersten Versuch in #59, nur hässlicher im Code.
Es müsste auch Kommentar am Skript-Anfang stehen, was es in diesem Fall mit den Zeilen 21 und 23 auf sich hat.
Das versteht sich, die Frage ist nur ob man diesen (kl)einen Schritt Leuten zumuten kann.
Der Vorteil von den fest integrierten Icons ist ja, dass niemand den JS Code auch nur öffnen muss - der Nachteil, ohne Eigeninitiative in entweder JS oder CSS: kein eigenes Icon.
Persönlich denke ich ja, Javascript Benutzer sollten den Schritt machen können; aber wir reden hier - wie so oft - eigentlich nur über User die komplett fertige Lösungen wollen oder brauchen, was ich auf eine Art auch verstehen kann.
Wenn es jetzt noch möglich wäre, einen automatischen Fallback einzurichten.
Eventuell zwei Zeilen, die erste ist von Anfang an aktiv und gibt den Pfad zur chrome://-Datei an und einen entsprechenden Kommentar. Und die zweite erst einmal auskommentierte Zeile mit einem Beispielpfad, wo der Kommentar angibt, dass man da eine eigen Datei angeben kann und dass man die Kommentarzeichen vor dieser Zeile entfernen und vor die erste Zeile setzen muss. Aber diese Zusammenbau-Variante verkompliziert das meiner Meinung nach.
Deshalb wäre eben ein Fallback wie in CSS perfekt, das kapiere ich aber nicht in JS.
Ansonsten, egal wie ein alternatives Icon angeboten würde, ob von Firefox oder über Endor's Seite - gleiches Prinzip, nur Zusatzarbeit für Endor - bräuchte es halt einen manuell zu schaltenden//kommentierenden Code.
Wie sowas, was aber auch kein Fortschritt ist zu meinem ersten Versuch in #59, nur hässlicher im Code.
//profile-button.uc.js tester icons
(function() {
if (location.href !== 'chrome://browser/content/browser.xhtml')
return;
try {
CustomizableUI.createWidget({
id: 'Profiles_button',
type: 'custom',
defaultArea: CustomizableUI.AREA_NAVBAR,
onBuild: function(aDocument) {
let currentProfileDirectory = Services.dirsvc.get("ProfD", Ci.nsIFile).path.replace(/\\/g, "/");
let buttonicon = "LettersP-1.png";
// tester
//eigenes icon
//let styler = 'list-style-image: url("' + ("file:" + currentProfileDirectory + "/chrome/icons/" + buttonicon) + '");';
//Firefox icon
let styler = 'list-style-image: url("chrome://browser/skin/translations.svg");';
let toolbaritem = aDocument.createElementNS('http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul', 'toolbarbutton');
let props = {
id: 'Profiles_button',
class: 'toolbarbutton-1 chromeclass-toolbar-additional',
label: 'Profiles',
tooltiptext: 'about:profiles',
// original
//style: 'list-style-image: url("' + ("file:" + currentProfileDirectory + "/chrome/icons/" + buttonicon) + '");',
// tester
style: styler
};
for (var p in props)
toolbaritem.setAttribute(p, props[p]);
return toolbaritem;
}
});
} catch(e) { }
document.getElementById('Profiles_button').addEventListener('click', event => {
if (event.button === 0) {
openTrustedLinkIn("about:profiles", "tab");
}
});
})();