Beiträge von Speravir

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:

• 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: ).

Zitat von 2002Andreas

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.

Zitat von 2002Andreas

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.

Zitat von Mira_Belle

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.

Zitat von Mira_Belle

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.

Zitat von .DeJaVu

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.

Zitat von Horstmann

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.

Zitat von .DeJaVu

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.

Zitat von Speravir

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.

Zitat von BarbaraZ-

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:

Zitat von visoer

#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.

Zitat von .DeJaVu

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.

Zitat von GermanFreme82

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.

Zitat von Fritz80

Bei dem Script von Aris

Aris hat das Skript gerade aktualisiert, und zwar genau im CSS-Teil. Damit ist auch dieses hier hinfällig:

Zitat von Speravir

wobei zu beachten ist, dass am Ende jeder Zeile immer ein Backlslash („\“) stehen muss.

Der CSS-Bereich beginnt jetzt ab Zeile 100.

Zitat von .DeJaVu

Bei mir haben die Profile den gleichen Namen wie der Ordner, und die sind frei gewählt.

Bei mir ist es genau anders herum.

Zitat von abifiz

"Form History Control" vermerkt, "was, wie" ich gemacht habe,

Ich versteh nicht, was Du damit meinst.

Zitat von abifiz

Das Einzige für mich Interessante ist mein entsprechender vollständiger Text. Und ausgerechnet der wird nicht festgehalten.

Bei mir schon. Eventuell musst du in den Einstellungen etwas ändern.

Zitat von Gim

Das Problem oder besser das was es umständlich macht ist, dass es nur per Seite geht und nicht wie mal früher für alle Seiten oder Cookies an einer Stelle zu sehen ist.

DejaVu hatte dich schon auf AMO hingewiesen. Addons, die sich mit Cookies beschäftigen, gibt es relativ viele. Ich würde den Cookie Quick Manager empfehlen. Man muss dort immer noch jede Domain durchgehen (was ich allerdings sinnvoll finde), aber das in einem Fenster/Tab. Die abgelaufenen Cookies sind rot markiert. Man kann das Addon zum automatischen Löschen nutzen, aber auch so einstellen, dass man es ausschließlich zum Betrachten der Cookies nutzt.

Zitat von Sören Hentzschel

regedit. Wenn man dort einen Schlüssel anlegt, kann man den Inhalt über ein Textfeld bearbeiten. Ob das, was man dort einträgt, einfach nur eine beliebige Zeichenkette ist oder der JavaScript Object Notation („JSON“) entspricht, ist diesem Textfeld und der Windows-Registry komplett egal. Die Registry hat keine Kenntnis darüber, was der Inhalt eines Registry-Eintrags bedeutet und was damit geschieht.

Ah, das ist es, was ich nicht verstanden hatte. Danke.

Zitat von Sören Hentzschel

Ich weiß nicht, ob du meine Begründung nicht verstanden hast oder ob du absichtlich meine Worte verdrehst,

Ich habe es gelesen, sehe es aber anders.

Zitat von Sören Hentzschel

der Voraussetzung, dass eine deutsche Schreibweise auf der offiziellen Webpräsenz nicht existiert, im Gegensatz zur englischen Schreibweise.

Was aber auch einfach daran liegen könne, dass es jeweils keine deutschsprachige Version der Präsenz gibt.

Zitat von Sören Hentzschel

Es wäre wünschenswert, wenn sich weitere Beiträge um das Thema drehten.

Ja, ich hatte es gestern noch dazu schreiben wollen, dann aber vergessen: Belassen wir es dabei, dass wir uns einig in unserer Uneinigkeit sind.