Nochmals Vielen Dank für die schnelle und sehr kompetente Unterstützung, damit ist das weekend gerettet.
Ja bei 15 Tabreihen sollte es reichen! (Es sei denn man hat wie Sören über 400 Tabs gleichzeitig offen) 
Freut mich, dass es doch noch funktioniert hat.
Wenn ein Code von diesem Schalter abhängt, führt also kein Weg daran vorbei, den CSS-Code anzupassen, so dass er nicht mehr von diesem Schalter abhängt. Sonst ist schon bald die nächste Anpassung notwendig.
Wenn true jetzt das voreingestellte Standardverhalten ist, müssen dann in Zukunft, bei Wegfall des Schalters, all die Sachen geändert werden, die bei false nicht richtig funktionieren, oder etwa umgekehrt?
Der wird nur gebraucht, wenn man eine Leiste, in diesem Fall die Tableiste, verschieben will.
Alles klar. Danke für die Erklärung...
Und dieser Schalter auf false:
layout.css.xul-box-display-values.survive-blockification.enabled
Wenn dieser Schalter auf false steht, dann sehen die Tabs folgendermaßen aus:
bei true so:
Ich kannte diesen Schalter gar nicht. Was hat der eigentlich sonst für eine Funktion?
...nur der Scrollbalken ist manchmal da und manchmal nicht, der muss noch weg.
Würde ich zwar nicht machen, weil du dann neue Tabs außerhalb der Tableiste nicht mehr siehst und du nicht mehr mit dem Scrollrad deiner Maus durch die Tabreihen scrollen kannst. Aber bitte:
Folgende Zeilen müssen dann gelöscht oder auskommentiert werden.
Jetzt hätte ich noch eine Frage, diese rot markierten Abstände bez. Das leere/unbenutzte Feld, kann man das auch irgendwie anpassen, so dass die Bezeichnung vom Tab auch die 130px nutzt und das vermutlich leere Feld für den eigtl. Scrollbalken da ist, den ich aber nicht benötige.
Die Mindestbreite der Tabs (130px) habe ich aus deiner alten userChrome.css übernommen. Das kannst du natürlich ändern, wirkt sich aber logischerweise auf alle Tabs aus und macht sie kleiner. Ob man die jeweilige Tabbreite dem Textinhalt individuell anpassen kann, weiß ich nicht.
Der äußere rechte Rand entsteht deswegen, weil die Tabreihen die einzelnen Tabs 'umbrechen' und in die nächste Zeile verschieben, sonst hättest du rechts abgeschnittene Tabs. Ändere mal die Größe des Hauptfensters, dann siehst du was ich meine....
So wie ich das sehe, treffen wohl die SVG-Dateien hier nicht zu, sondern GIF-Dateiein, die in der Datei scrollbar.css festgelegt sind:
chrome://global/skin/scrollbox.css
Die SVG-Datei ist den Selektoren .tabbrowser-arrowscrollbox::part(scrollbutton-up) und .tabbrowser-arrowscrollbox::part(scrollbutton-down) zugewiesen. Und da hast du dann auch recht.
Ich glaube nicht, dass die Bilddateien aus chrome://global/skin/scrollbox.css kommen. Schau dir da mal die gifs an, die sehen ganz anders aus und sind winzig ( ich glaub, die sind eher für scrollbare Menü-Popups gedacht). Auch bei scrollbutton-down / scrollbutton-up werden wohl die svg-Dateien genommen. Sonst würden die Pfeile beim Vergrößern nicht so aussehen:
Ich versteh die ganze Sache ehrlich gesagt überhaupt nicht mehr. Da die Shadow-DOM Geschichte für die weitere Zukunft der userChrome-Anpassungen wichtig ist, wäre es schön, die Thematik noch einmal prinzipiell und technisch zu diskutieren.
Vielleicht besser in einem eigenen Thread... 
Hallo,
Danke für deine schnelle Rückmeldung. Ich habe jetzt die chrome mit oben genannten ersetzt. Leider zeigt diese überhaupt keine Wirkung. Weder eine mehrzeilige Tableiste, eine mehrzeilige Faviconleiste oder sonst etwas
Gebe bitte in der Addressleiste about:config ein und gib in dem sich öffenenden Suchfeld dann toolkit.legacyUserProfileCustomizations.stylesheets ein.
Falls dieser Wert auf false steht, ändere ihn mittels Doppelklick auf true.
Außerdem musst du beim Kopieren aus dem Code-Feld aufpassen, dass du wirklich alles genauso kopierst.
Ich habe den Code nochmals getestet und er funktioniert hier einwandfrei.
Ersetze bitte deine ursprüngliche userChrome.css mit nachfolgendem Inhalt:
Wichtig: Mit dem Code werden keine optischen Änderungen an den Tabs vorgenommen (außer Größenangaben).
Auch das Verschieben der Tabs funktioniert nicht richtig, da dafür User-JavaSkripte notwendig wären. Falls du das wünscht, muss du, erst den FireFox für Skripte vorbereiten. Dazu gibt es eine bebilderte Anleitung: UserSkripte aktivieren. Und dann die im Link angegebene JS-Datei in dein Chrome-Verzeichnis einfügen: MultiTabRows
Eine Sache verstehe ich überhaupt nicht, wenn ich den Code von milupo in die Entwicklungsumgebung einfüge, dann funktioniert er nicht, in der userChrome.css schon.
Außerdem scheint es sich doch bei den Pfeilen um svg-Grafiken zu handeln und die könenn doch nur über 'fill' umgefärbt werden, und nicht über 'color:'
Ich frage mich bloß, warum ich dann überhaupt diese starke Kapselung (sprich Shadow-DOM) seitens Mozilla anwende, wenn nicht deswegen, weil ich bei immer komplexer werdenden Projekten auf Nummer sicher gehen will und eben den Gültigkeitsbereich meiner Bezeichner künstlich einschränke. Das ist ja im Prinzip das gleiche wie bei namespace-Blöcken. Dass die IDs wirklich überall auf jeden Fall eindeutig sind, muss nicht zwingend sein. Da ich ja davon ausgehe, dass sie bei den FF-Entwicklern über part() angesprochen werden, was ja leider in der userChrome.css so nicht funktioniert.
Bei mir scheint es aber mit:
[...]
zu funktionieren.
Ja, das stimmt. Wenn man die Klassen '.scrollbutton-up' ,'.scrollbutton-down' global anspricht, dann geht es. In diesem Fall wohl auch ohne Seiteneffekte (konnte zumindest keine finden). Ich denke, dass Shadow-DOM wurde aber gerade deswegen entwickelt, um gleiche IDs und Klassennamen zu kapseln, damit sie nicht plötzlich etwas verändern, was man nicht verändern will. Wenn irgendwo anders die gleichen Bezeichner verwendet werden für Scrollbuttons, dann wären die jetzt auch weiß/dunkelgrau.
Aber wie gesagt, in diesem Fall funktioniert es wohl sehr gut und daher dürfte sein Problem mehr oder weniger gelöst sein.
Ich denke, dass wird schwierig werden, da wir hier das Problem mit den gekapselten Shadow-Roots haben. D.h. Die ScrollButtons sind als quasi abgeschlossenes Custom-Element definiert. In diesem Fall ist die Shadow-Root zwar offen und besitzt auch ein part Atribute, kann aber über die userChrome.css nicht angesprochen werden . In der Entwicklungsumgebung funktioniert das Ändern (z.B der Farbe) ohne Probleme. Ob es da irgendwelche Tricks gibt oder ob man da was über JS machen kann, weiß ich nicht.
Rob : Bitte das mal testen: ('@-moz-document'-Anweisung natürlich nur hinzufügen, wenn noch nicht vorhanden). Sonst nur Zeile 4-15 hinzufügen.
Schaut dann so aus:
Als Ergänzung zu dem was 2002Andreas gepostet hat:
Es müssen ein paar Zeilen im oberen Skript geändert werden, damit die Addresseingabe der neuen Seite auch den Fokus erhält. Betrifft die Zeilen 21-34 in dem Code.
Hier nochmal der gesamte Code mit Änderungen
Ein ähnliches Problem hatte ich vor einiger Zeit auch. CSS geht, Skripte nicht mehr.
Bei mir hat es geholfen FF einmal im abgesicherten Modus zu starten, zu schließen und wieder neu zu starten. Danach liefen alle Skripte wieder. Außerdem könntest du das Verzeichnis 'startupCache' in deinem Profilverzeichnis löschen.
Freut mich, wenn es bei dir funktioniert...
Ok, hatte ich mir dann auch schon gedacht, dass das nur ein Platzhalter für weiteren Code ist...
Ansonsten kann ich da nichts falsches entdecken.
Der '@namespace'-Eintrag muss allerdings nach den @import-Einträgen kommen. Der @import steht immer an erster Stelle in der Datei....
zu1) Das musst du nur machen, wenn bei dir UserScripte laufen sollen. Siehe: firefox-anpassungen-die-basis
zu 2) Ja, da ist ein Fehler drin (falls du das nicht eben noch in den Code eingefügt hast
In Zeile 9 muss der Schrägstrich(in Spalte 2) vor den Stern, also so /*(css Code xyz)*/
