Beides ist der private Modus.
Ich sehe das anders 
: Auf dem ersten Screenshot sieht man, dass mit '-private' nur 'about:privatebrowsing' aufgerufen wurde. Im zweiten Screenshot ist mit '-private-window' dann wirklich ein privates Fenster aufgegangen.
"C:\Program Files (x86)\Mozilla Firefox\firefox.exe" "-private"
Muss es nicht -private-window heißen? -private funktioniert hier jedenfalls nicht (nur mit Nightly getestet!).
.tabbrowser-tab:not([visuallyselected=]) > .tab-stack > .tab-background {
Da ist noch ein Fehler in Zeile 38... 
Ich mache darauf einen Doppelklick, dann wird sie mit dem Fx geöffnet.
Und mit meiner Regel wird der CSS Code geladen.
Mit deiner Regel funktioniert es mit jeder PDF-Datei, egal ob lokal gestartet oder über einen Download, da ja der Dateityp herausgefiltert wird.
Mit der Regeln von Ralf muss ich den genauen Ordner angeben, wo die Datei liegt.
Dann funktioniert es damit auch.
Ralf ist davon ausgegangen, dass die Einstellung browser.download.start_downloads_in_tmp_dir dafür sorgt, dass eine PDF-Datei, die im Firefox angezeigt werden soll, sich immer in diesem Temp-Verzeichnis befindet, was aber, wie ich weiter oben beschrieben habe, eben nicht der Fall ist.
Ich habe ja bestätigt, was du geschrieben hast. Was anderes wollte ich mit meinem Posting gar nicht zum Ausdruck bringen...
Mit anderen Worten:
Die regexp()-Lösung ist wohl die einzige(?) Möglichkeit, die Regeln auf den PDF-Viewer zu beschränken.
Die → browser.download.start_downloads_in_tmp_dir Pref sollte das eigentlich gewährleisten, oder?
Funktioniert hier so nicht.
Das funktioniert auch nicht immer. Wenn z.B. in den Einstellungen 'Immer mit Firefox öffnen' ausgewählt ist, dann muss Firefox sie ja nicht im Temp-Ordner (nicht mal im Cache) zwischenspeichern. Es wird direkt vom RAM-Speicher aus angezeigt. Das Speichern im Temp-/bzw. Downloadordner dient in erster Linie dazu, die PDF-Datei für eine andere Applikation (z.B. Adobe Reader) verfügbar zu machen, damit sie von dort geöffnet werden kann, wenn z.B. 'mit Adobe Reader öffnen' voreingestellt wurde.
Ich hoffe das passt dann so:
Funktioniert einwandfrei, sehr gut... 
Keine Ahnung ob es evtl. sogar eine @-moz-document Regel dafür gibt
Möglich, vielleicht sogar mit regexp(), aber da steht bei Mozilla, dass das deprecated ist. Ob und wie man die Regeln auf den PDF-Viewer beschränken kann, wüsste ich jetzt auch nicht. Vielleicht weiß ja Sören Hentzschel was...
Eben mal getestet, funktioniert hier warum auch immer in beiden Dateien
Auch noch mal getestet. Bei mir läuft es definitiv nur in der 'userContent.css', in der 'userChrome.css' hingegen nicht.
Der Code muss in die userChrome.css rein.
Du meinst sicher userContent.css, oder ?
Außerdem sollte man beachten, dass dann Sachen wie '.toolbarButton' oder '#pagenumber' sicher auch auf anderen Webseiten verwendet werden, müsste man also spezifischer für *.pdf Dokumente machen.
Das Update vom 24.10. habe ich mal übernommen und angepasst. Dabei ist mir aufgefallen, dass dort noch eine Kleinigkeit offen ist (nehme ich an
Danke für den Hinweis. In der Nightly hatte ich das bei mir schon geändert, aber noch nicht für die Release, für die ich dann ja die neue Version eingestellt hatte. Funktionieren tut es allerdings bei .tabbrowser-tab auch noch mit der Angabe des Bool-Wertes, auch noch in FF121.
also ganz unten
Dann musst du noch das hier var nTabbarPosition = 6; in den UserSettings eintragen...
wenn ich das script tabbaratbottom.uc.js mit reinlege geht wieder nichts
Das Skript brauchst du nicht. Bitte wieder löschen!
Hilfe - seit dem heutigen Update (119)(64 bit) ist die Leiste komplett verschwunden. Also auch nicht oben zu sehen sondern einfach weg????
Ich vermute(!), du bist im falschen Thread...
Falls du noch die mehrzeilige Tableiste nutzt, dann musst du die neueste Version dieses Skripts nutzen:
Wichtig: Dieses Skript wird nicht mehr weiterentwickelt. Die letzte Firefox-Version, die noch unterstützt wird ist 137.
Leider zu früh gefreut
Das leidige Problem mit den nicht mehr sichtbaren angehefteten Tabs ist immer noch da.
Du hast also mit diesem Skript bzw. mit dem geupdateten Skript aus dem Startbeitrag noch die gleichen Probleme wie vorher?
Könntest du bitte auch mal mit der aktuellen Version FF119 oder der Nightly FF121 testen und mitteilen, ob da das Problem dort auch besteht?
Ich komme wohl erst am Wochenende dazu, der Sache noch einmal eingehend zu untersuchen. Das wird sich allerdings schwierig gestalten, weil ich diesen Fehler bei mir immer noch nicht nachvollziehen kann.
mr.b. Ist bei dir der Fehler noch einmal aufgetreten?
Hier *war* sie dort leider nicht.
Und wenn du das Skript entfernst, ist dann die Tableiste wieder da?
Steht bezüglich deines Scripts bzw. deines Problems eine Meldung in der Konsole ([Strg]+[Shift]+[J])?
Am besten hier alle Haken entfernen, und nur bei Bedarf übersetzen lassen:
Genau... 
Lässt du die Seite übersetzen?
Sehr gut beobachtet...
Lisa. hat die Option "Englisch immer übersetzen" eingeschaltet und da für die angegebene Webseite als Sprache "englisch" im Quelltext gesetzt wurde, versucht sich der Übersetzer daran den deutschen Text als englischen Text zu interpretieren und wieder nach "deutsch" zu übersetzen.
Das letzte Skript von aborix funktioniert hier in FF118 einwandfrei.
Hast du auch den (aktualisierten!) Link aus #41 von Zitronella aufgerufen?
Es müssen ab FF115 zwei Dateien ausgetauscht werden.
diese UserScript funktioniert nicht mehr mit Firefox 115 Version.
Darf ich fragen, wozu du dieses Skript brauchst? Das Kopieren des Quelltextes über eine Auswahl ist doch schon im Firefox enthalten. Oder ist es der zusätzliche Klick um die selektierte Vorschau des Quelltextes dann endgültig in das Clipboard zu kopieren, der dich stört?
Mozillas Release Management ist damit einverstanden, den Bugfix in Firefox ESR 115 zu integrieren.
Wow, du hast Kontakt zum (Release-)Management... 
?! Vielen Dank für deine Bemühungen .
Dann hoffe ich nur, dass mein Fehler auch wirklich damit in Verbindung steht, da ich ja hier im Forum anscheinend der einzige bin, bei dem dieses Verhalten zu beobachten ist.
Ich nutze sie für einen Teil (9) meiner Erweiterungen/Skripte und deren Button.
Gut, dann ist das für dich natürlich noch keine Lösung. Aber ich denke, so wirklich schlimm ist der verschwundene Erweiterungs-Button eigentlich auch nicht. Es sei denn, man ist ständig mit mehreren Fenstern unterwegs...
Der entscheidende Grund, warum der Button verschwindet, ist die Funktion CustomizableUI.registerArea() in Zeile 15.
Kommentiert man diesen Aufruf aus, kann man dort zwar keine Toolbar-Buttons mehr ablegen, aber ansonsten verhält sich die Leiste normal und der Erweiterungsbutton verschwindet nicht und funktioniert, wenn man ein neues Fenster öffnet.
Wer die Leiste wirklich nur als Statusleiste nutzen möchte (so wie ich) , für den mag das ja vielleicht schon ausreichend sein...
