Nö.
https://phabricator.services.mozilla.com/D170368: „Needs Review“https://bugzilla.mozilla.org/show_bug.cgi?id=1809084: „Open“ / „firefox112 - affected“
Ich konnte beide Links nicht öffnen (Edit: ...der Doppelpunkt war's). Aber Fakt ist doch, dass der Fehler in FireFox 112 behoben wurde. Ob das nun durch den angegeben Patch oder eine andere Änderung geschehen ist, spielt doch für die Betroffenen keine Rolle... 
Der von mir verlinkte Patch ist noch nicht einmal in der Nightly-Version von Firefox 112 gelandet.
Muss er aber, sonst würde ja das Merken der Scrollposition in FireFox 112 nicht wieder funktionieren.
der Fehler wurde mit Firefox 111 noch nicht behoben.
Die Beta bzw. die noch nicht freigegebene Release 111 nutze ich nicht, aber in der aktuellen Nightly 112 tritt der Fehler nicht mehr auf!
Ich wollte mit dieser kleinen Randbemerkung sicher keine Grundsatzdiskussion über KI-basierte Chatbots führen, zumal das in diesem Thread ja vollkommen OT wäre. Kann jeder selber testen und die Frage der Sinnhaftigkeit dann für sich beantworten...
Nur eine Korrektur:
Im Übrigen ist der zu Grunde liegende Datenbestand noch auf dem Stand des Jahres 2021. Alles, was danach passiert ist, kennt ChatGPT überhaupt nicht.
Das gilt nicht für die Bing-Version, die hat diese Einschränkung nicht:
Im Gegensatz zu ChatGPT, welches Trainingsdaten bis ins Jahr 2021 enthält, besitzt Bing Zugriff auf aktuelle Daten.
Ok, der Klops ist ja schon gegessen, aber noch der Vollständigkeit halber:
Die gepatchte 'omni.ja' -Datei funktioniert doch! 
Allerdings muss man nach dem Austauschen dieser Datei ein neues Profil anlegen und dann erst die Lesezeichen in die Lesezeichenleiste einfügen/importieren. Habe hier mehr als 500 Lesezeichen, die er auch wirklich alle in der mehrzeiligen Symbolleiste darstellt. Der Grund, dass es bei einem bestehenden Profil nicht funktioniert, dürfte sein, dass sich Firefox die maximal darstellbare Anzahl an Lesezeichen (hier 120) irgendwo im Profil merkt. Ich weiß allerdings nicht, wo er das abspeichert? In 'about:config', 'places.sqlite' und 'xulstore' habe ich nichts gefunden.
Aber trotzdem ist das wohl alles nicht sehr praktikabel, wenn es erst in einem neuen Profil funktioniert. Außerdem müsste man den Patch ja noch in ein User-Javascript packen, da man ja nicht bei jedem Update die 'omni.ja' austauschen möchte. Und wahrscheinlich würde das auch nicht funktionieren, da Firefox sich vielleicht schon beim allerersten Start die maximal darstellbare Anzahl von Lesezeichen merkt und damit das User-JSkript zu spät aufgerufen wird...
War jetzt also nur von 'akademischem' Interesse... 👨🎓
Ich kann warten, die Hoffnung habe ich längst nicht aufgegeben.
Optimist 
Da findet sich bestimmt auch etwas …
Ich muss zugeben, dass ich Edge(
) in letzter Zeit wirklich häufiger nutze, da ich die ChatGPT-Version in Bing gerade ausprobiere und das funktioniert nur mit dem MS-Browser.
Da warst du ja mal wieder richtig fleißig
Nicht wirklich, bin eigentlich immer ziemlich faul 
, FuchsFan weiß wovon ich rede , Es gibt aber komischerweise immer wieder Probleme/Fragen, die mich auf eine Art herausfordern, die dann die Suche nach einer Lösung/Antwort quasi fast 'zwanghaft' werden lassen. Damit das nicht wieder passiert werde ich heute den Rest des Tages 'Firefox-abstinent' bleiben und nur mit dem Edge unterwegs sein 
...
.
.Quatsch, war natürlich ein Scherz! So schlecht ist mein Zustand auch wieder nicht... 
sondern mehr einzelne Ordner zu verwenden.
Ich werde dann mal meine Lesezeichen aufräumen und in Ordner schieben.
Hat mir keine Ruhe gelassen...
Wie ich vermutet hatte, berechnet Firefox die maximale Anzahl der darzustellenden Lesezeichen aus der 'Screen-Width' (1920px) und teilt das dann durch die Höhe des Lesezeichen-Buttons (24px, Höhe, weil er ein Quadrat annimmt). Ich hatte zum Test 261 Lesezeichen eingefügt und laut der Berechnung ergibt sich für min(261,(1920*1,5/24)) eben 120, was bei mir exakt der dargestellten Zahl an Lesezeichen in der mehrzeiligen Leiste entspricht.
Die entsprechende Zeile befindet sich in der browserPlacesView.js in Zeile 1019, siehe Screenshot:
Ich denke, dass man genau diese Zeile patchen müsste, indem man immer den Wert der Variable cc zurückgibt.
Ich weiß natürlich nicht, ob hier noch andere Nebenbedingen gelten müssen und ob dies die einzelne Stelle ist, welche man anfassen muss?!
Wie gesagt, wahrscheinlich zu viel Aufwand, für das gewünschte Ergebnis ...
Edit: Habe die Zeile mal wie oben beschrieben in der 'omni.ja' gepatcht, und siehe da: this doesn't do the trick 
Ich habe eben mal rund 150 Lesezeichen in die Lesezeichensymbolleiste eingefügt, und kann dein Problem dann bestätigen.
Der Grund dürfte folgender sein:
Mozilla geht ja von einer einzeiligen Lesezeichenleiste aus und wenn man dann die kleinstmögliche Breite eines Lesezeichens nimmt, dann dürfte das 16 Pixel sein, eben nur das Icon, plus etwaige Abstände. Mein Monitor hat eine Auflösung in der Breite von 1920 Pixel. Also 1920/16 = 120 Lesezeichen. Dieser Wert ist dann das berechnete Maximum an Lesezeichen und bleibt natürlich auch bei einer mehrzeiligen Lesezeichenleiste bestehen. Wenn man sich die DOM-Eigenschaften der Scrollbox anschaut, dann sieht man auch, dass (hier) wirklich nur 120 Lesezeichen vorhanden sind.
Wenn die Lesezeichenleiste einzeilig ist, dann stehen ja die nicht mehr darstellbaren Lesezeichen im Popup des Chevron '>> ' zur Verfügung. Diese Logik kann man wohl nur ändern, wenn man irgendwo den Firefox-Code patcht. Ich denke zwar, dass das möglich ist, aber das wäre ein Aufwand, der wohl in keinem Verhältnis dazu steht, einfach die Anzahl der Bookmarks zu reduzieren bzw. in Ordner zu organisieren...
Ich vermute ebenfalls, dass der TE in der Vergangenheit diese Einstellung (bewusst?) in einer ziemlich alten Version vorgenommen hat, als dieser Schalter noch über den normalen grafischen Einstellungsdialog erreichbar war. Und Firefox hat dann, nach Wegfall dieser Option in den Einstellungen, diesen Wert nach einem Update in den 'about:config'-Schalter unverändert übernommen. Er schreibt ja nicht, seit wann er schon dieses Problem hat?
Wird die Zeichenkette 29195B6E-94A8-4883-A590-50D5C135E951 mittels regedit in der Registry gefunden?
Ich habe, wie weiter oben angeregt, auch über Procmon nachgeschaut und es werden definitiv keine Daten beim Download von Firefox in irgendeine Datei geschrieben, wenn der Cache abgeschaltet wird (Disk&Memory-Cache haben jeweils 0 Einträge!). Die gesamte PDF-Datei befindet sich also ausschließlich im allokierten RAM und wird dann gleich im Firefox zur Anzeige gebracht, sobald die Datei richtig übertragen wurde.
Das ist das, was ich auch ganz am Anfang gesagt habe und wo man mir immer wieder erklärt hat, dass das technisch gar nicht möglich sei. Und die ganze Diskussion nur, weil ich in meinem ersten Beitrag in diesem Thread einem Fragesteller erklärt hatte, dass er keine PDF-Datei finden kann, weil gar keine angelegt wurde...
--
Paktebasierte Übertragung mit Paketgrößen, die nahezu immer kleiner sind als die zu übertragenden Dateien?
Was hat TCP mit der Frage zu tun, ob ich eine Datei/Cache für das "Zusammensetzen"(?) übertragener Datenpakete brauche? Es werden keine Paketdaten in der Größenordnung von ca. 1,5KB in den Cache geschrieben, das wäre viel zu ineffektiv, sondern meist ein Vielfaches davon(kann man ja auch in Procmon überprüfen). Die einzelnen Datenpakete werden bei der Übertragung zuerst in einem oder mehreren dynamischen Speicherobjekten gehalten und dann zum Zwecke der Wiederverwendung in den Cache geschrieben oder zum Öffnen in anderen Anwendungen temporär gespeichert(z.B. %temp%) bzw. persistent gespeichert, wenn ich eine Datei dauerhaft speichern möchte ("Download").
...und vor allem: wie werden die Daten bitte nach deiner Aussage im Cache/Datei zusammengesetzt und im Firefox zur Anzeige gebracht, wenn überhaupt kein Cache oder temporäre Datei existieren?
Pfeif auf Dateisystem, aber zuletzt erklärtest du, dass gar keine Speicherung vor der Anzeige nötig sei
Was du mit diesem Satz meinst, verstehe ich nicht...
Eventuell beisst dich du dich zu sehr an Begrifflichkeiten fest und verlierst darüber die technischen Aspekte aus dem Blick :-/
Ich habe leider das Gefühl, dass ich der einzige hier im Thread bin, der sich nicht an Begrifflichkeiten festbeißt, sondern an den technischen Gegebenheiten...
Es war immer von einer PDF-Datei die Rede, welche der TE bei "Anzeige im Firefox" auf seinem Dateisystem nicht finden kann und es war hier mehrfach die Behauptung aufgestellt worden, dass diese PDF-Datei immer erst im Dateisystem abgespeichert werden muss, weil dies technisch notwendig sei. Einfach nochmal den gesamten Thread durchlesen. Deswegen wurde doch der %temp%-Ordner und der Disk-Cache ins Spiel gebracht. Später war dann die Datei auch noch im Memory-Cache, weil es angeblich notwendig ist, sie dort zu speichern und jetzt sagst du das gleiche, dass die Datei im Cache zusammengesetzt wird und dann erst zur Anzeige ins RAM geladen wird. Die Datei befindet sich doch schon im RAM!? Welche technische Begründung gibt es denn für so ein Vorgehen (außer bei sehr großen Dateien, um nicht nochmal alles vom Server laden zu müssen)?
Vor allem hatte ich aber doch gezeigt, dass alles auch ohne Zwischenspeicherung angezeigt werden kann und zwar indem man den gesamten Cache abschaltet und dort auch nachweislich nichts mehr abgespeichert wird (siehe 'about:cache'). Warum probiert das denn keiner aus? Ich versteh diese Diskussion echt nicht mehr...
Trotzdem werden die Daten von einem Server herunter geladen, also auf englisch ein download.
Ich glaube, dass du das falsch verstanden hast. Dass die Daten von einem Server auf deinen Rechner "heruntergeladen" werden und zwar im Sinne einer Datenübertragung via Internet-Protokoll ist natürlich vollkommen klar und unstrittig. Werden ja nicht per Zauberbefehl dahin "teleportiert". Hier wurde aber von mindestens drei Leuten behauptet, dass es technisch notwendig sei, die Daten unbedingt irgendwo zu speichern, bevor man sie anzeigen kann z.B. eine PDF-Datei. Erst war vom %temp%-Ordner die Rede, dann der Disk-Cache und jetzt wird sogar der 'Memory-Cache' als notwendiger Speicherort angegeben. Ich war in der Diskussion immer der Meinung, dass es nur notwendig ist, die Daten im RAM-Speicher zu halten und bin es immer noch...
das ändert aber nichts daran, dass die zu betrachtende Datei vom Server heruntergeladen und im Cache gespeichert wird.
Nein. Wenn sowohl der Memory-Cache browser.cache.memory.enable -> false, als auch der Disk-Cache( 'persistent' ist in diesem Zusammenhang nicht richtig, ich hatte das fälschlicherweise auch mal verwendet) abgeschaltet sind, dann wird die Test-PDF-Datei weder im Memory-Cache , noch im Disk-Cache (zwischen-)gespeichert, auch im %temp%-Ordner nicht. Unter 'about:cache' gut nachzuvollziehen -> Keine neuen Einträge vorhanden.
Die PDF-Datei wird aber fehlerfrei angezeigt und man kann sie auch abspeichern.
verwende jetzt einen „Brokenmilupo“-Code
Wenn "In Firefox öffnen" eingestellt ist, funktioniert die Anzeige eines PDF auch ohne eingeschalteten persistenten Cache. Auch dann werden keine Dateien im %temp%-Ordner angelegt. Einfach mal ausprobieren
Hatte ich längst getan und in #26 beschrieben, dass die Datei in diesem Fall im Cache landet. Also wird auch in diesem Fall die Datei gespeichert.
Gruß Ingo
Wenn der Cache ausgeschaltet ist, kann überhaupt nichts im Cache gespeichert werden!
Zum Testen:
Das Cache-Verzeichnis von der Platte putzen und
unter about:config -> browser.cache.disk.enable auf false setzen.
Dann bleibt das Cache-Verzeichnis leer, egal was runtergeladen wird.
Ja, guten Morgen, milupo.
Seh's doch von der positiven Seite und kommuniziere das auch so:
"Problem konnte erfolgreich durch ausgiebige Tests und Einfügen eines zusätzlichen CSS-Befehls in kürzester Zeit gelöst werden."
So hätte ich es vor Jahren meinem Chef verkauft...
Dein Code zeigt nur eine Zeile.
Bei mir nicht:
Hast du Firefox mal neu gestartet?
Ja, auch dann sind alle Einträge da und sichtbar...
versuch mal diesen Code-Schnipsel....
/* ------------------------------- */
/* Mehrstufige Lesezeichen-Toolbar */
/* ------------------------------- */
#PersonalToolbar
{
max-height: 100px !important;
}
#personal-bookmarks,
#PlacesToolbar,
#PlacesToolbar > hbox
{
display: block;
}
#PersonalToolbar toolbarbutton
{
min-height: 20px !important;
max-height: 20px !important;
}
#PlacesToolbarItems
{
max-height:100px!important;
display: flex!important;
flex-wrap: wrap!important;
overflow-x: visible!important;
overflow-y: auto!important;
/*contain: none !important;*/
}
#PlacesToolbar,
#PersonalToolbar > scrollbar
{
;
}
#PlacesToolbar #PlacesChevron
{
display: none;
}Gerade deinen Code getestet und der funktioniert bei mir auch hier, müsste also an was anderem liegen
Hallo
Hallo schlingo,
dann liegt die Datei aber eigentlich in %temp% und nicht im Cache.
Nein, die Datei wird weder im Standard-Download-Verzeichnis, noch in %temp% gespeichert, wenn die Einstellung "in Firefox öffnen' ausgewählt ist. Wozu auch? Das wird ja nur gebraucht, wenn ich die Datei mit einer anderen Anwendung öffnen möchte, um der anderen Anwendung eben den Zugriff auf die Datei zu gewährleisten.
Was den sonst? Selbstverständlich ist eine Datei im Cache rein technisch eine Datei wie jede andere.
Ich habe ja auch nicht geschrieben, dass es keine Datei ist, sondern dass man unter einer Datei im Cache keinen Download versteht, so wie der Begriff 'Download' definiert und auch allgemein verwendet wird. Der Cache könnte auch aus einer einzigen großen Datenbank-Datei bestehen, auf die du nicht einfach über das Dateisystem Zugriff hast. Im Cache werden Daten gespeichert. Dass es sich dabei meistens auch um einzelne Dateien handelt, ist nur eine Frage der Implementation.
Jede Datei kann wieder gelöscht werden, früher oder später.
Ja. Aber bei einer Datei, die ich bewusst zum Zwecke der Speicherung heruntergeladen habe, bestimme ich den Zeitpunkt des Löschens.
Auch %temp% ist nicht für den "direkten Zugriff" gedacht.
Richtig. Aber als Ort, um die Datei mit einem anderen Programm zu teilen (z.B. Adobe Acrobat), benutzt Firefox dieses Verzeichnis ,falls in about:config so eingestellt.
Noch was: Wenn "In Firefox öffnen" eingestellt ist, funktioniert die Anzeige eines PDF auch ohne eingeschalteten persistenten Cache. Auch dann werden keine Dateien im %temp%-Ordner angelegt. Einfach mal ausprobieren...