Beiträge von BrokenHeart

Zitat von Upgrader

Trotzdem würde ich für mein Verständnis noch gern geklärt haben, warum sich manche pdf (gewollt) in einem neuen Tab öffnen, aber eben nicht automatisch im Hintergrund in das Standard-Download-Verzeichnis von Windows 10 heruntergeladen werden, obwohl ich in about:config die Grundeinstellung noch nicht geändert habe.

Dass du die PDF-Datei nicht im Dateisystem findest, ist vollkommen normal, da du "in Firefox öffnen" in den Einstellungen ausgewählt hast. Dann wird die PDF-Datei auch nicht abgespeichert (höchstens Firefox-intern zu Caching-Zwecken unter einem anderen Namen). Wenn die Datei in Firefox angezeigt wird, ist es nicht notwendig, dass sie abgespeichert wird.

Zitat von rb.frank.zappa

macht alles kein Sinn. Sehr viel unqualifizierte Bemerkungen, die nicht zur Lösung beitragen.

Ja, in Foren gibt es prinzipiell immer eine Menge Rauschen und auch Müll, weil hier eben Leute mit unterschiedlichen Wissensständen und Fähigkeiten mitdiskutieren. Wenn man Glück hat, dann trifft man gleich in den ersten Antworten auf jemanden, der einem den richtigen Weg weist. Oft ist das eben nicht der Fall. Aber in deinem eigenen Interesse würde ich nicht schon nach einem Tag einen theatralischen Abgang hinlegen und mit "macht alles keinen Sinn" hier das Thema abhaken. Vielleicht hätten sich ja mit etwas Warten eben doch noch Leute gefunden, die dir den entscheidenden Tipp geben. Du hast außerdem doch einige Hinweise und auch eine mögliche Fehlerquelle genannt bekommen und es wäre schön gewesen, wenn es von deiner Seite wenigstens ein Feedback gegeben hätte...

Zitat von .DeJaVu

Und zu "webrtc" gibt es im about:config keinen weiteren Begriff mit "leak", nicht mal "leak" als solches.

media.peerconnection.enabled auf false und kein "Leak" mehr.

Da fällt mir gerade ein: falls er das gemacht hat (den Wert auf false gesetzt), könnte das auch mit seinen Problemen bei Kamera und Micro zusammenhängen...

Zitat von .DeJaVu

Komplett sinnfreie Erweiterung.

Wo schreibt er, dass er eine Erweiterung zum Verhindern des WebRTC-Leaks benutzt?

Das Abschalten ist im Firefox mit nur einem Eintrag unter 'about:config' erledigt.

Auf dem Screenshot ruft er nur eine WebRTC-Leak Test-Webseite auf, die um Erlaubnis für den Zugriff auf Kamera, Micro nachfragt.

Zitat von .DeJaVu

Tritt eigentlich mit Android auch die Fehlinterpreation "rv:11" auf?

Hier im Forum lesen Leute mit ganz unterschiedlichem Wissenshintergrund mit und von daher fände ich es angemessen, wenn du kryptische Begriffe wie "rv:11" - auch wenn an eine bestimmte Person adressiert - erklärst.

Ich bin auch erst nach einer Google-Suche über Umwege ("Tier-Globuli von Dr. Reckeweg" ?!), dann auf das Einfrieren des User-Agenten im Firefox v110 wegen Namensgleichheit zum Internet Explorer 11, gekommen...

Zitat von Mokka123

Immerhin ein was Positives hat mein Problem gebracht

Du sagst es und ich bin dir auch wirklich dankbar dafür...

Zitat von Mokka123

Habe die Einstellung geändert, aber ich kann keine Veränderung feststellen. Lesezeichenmenü wird direkt wieder nach Aufruf eines Lesezeichens geschlossen.

Ja, es funktioniert nur mit der mittleren Maustaste, um mehrere Lesezeichen im Hintergrund zu öffnen. Das hatte ich übersehen. Dann ist das wohl doch nichts für dich...

---

Für mich ist dieses Verhalten allerdings ideal. Mit der linken Maustaste öffnet sich der Link im aktuellen Tab ganz normal und das Menü verschwindet wieder automatisch und wenn man mehrere Lesezeichen im Hintergrund öffnen will, dann bleibt das Menü beim Klick mit der mittleren Maustaste offen.

Zitat von Sören Hentzschel

Das Problem ist demnach bekannt - eine Korrektur ist aber noch nicht in Arbeit. Das wird aber ganz bestimmt noch passieren, immerhin gibt es davon auch schon mehrere Duplikate.

Da bin ich froh, dass es ein Bug ist und keine Änderung im Design...

Eine Lösung, die fast das alte Verhalten wiederherstellt, wäre:

Eingabe in Adressleiste 'about:config' -> suchen nach browser.bookmarks.openInTabClosesMenu -> von true auf false umschalten.

Dann wird das Lesezeichenmenü nach Aufruf eines Lesezeichens nicht sofort geschlossen. Das passiert erst, wenn du außerhalb des Menüs wieder mit der Maus klickst (oder [ESC] drückst). Bei einem wiederholten Aufruf des Lesezeichmenüs hat sich Firefox dann aber die Position, so wie in der Version zuvor, gemerkt.

Vielleicht ist ja das eine Lösung für dich....

Habe gerade festgestellt: diese Einstellung hat noch einen weiteren für mich sehr wichtigen Vorteil: Man kann dann mit der mittleren Maustaste über das Lesezeichenmenü mehrere Seiten auf einmal im Hintergrund öffnen, so wie bei der Sidebar. Somit könnte man dann eigentlich auf die Sidebar verzichten. So eine Funktion suche ich seit Ewigkeiten. Sehr gut gemacht BrokenHeart...

Zitat von .DeJaVu

Und nein, auch die v110 speichert den Stand nach scrollen.

Du musst das Lesezeichen natürlich noch aufrufen, danach ist er wieder auf Position 1!

Zitat von 2002Andreas

Sorry also für meine Antwort aus Beitrag Nr. 12

"Alles ist gut"...

In der Lesezeichenleiste hat man das Verhalten auch geändert (Test mit 102esr). Vielleicht weiß ja Sören Hentzschel was über die Intention oder ob das ein Bug sein könnte?

Zitat von Mokka123

Vielen Dank für deinen Beitrag und die Bestätigung

Gerne. Aber unabhängig von dem wohl dauerhaft geänderten Verhalten (in der Nightly geht es auch nicht), würde ich deine Vorgehensweise beim Aufruf der Lesezeichen ändern und die Lesezeichen z.B. über die Sidebar aufrufen. Da ersparst du dir so oder so eine Menge Klicks, falls du z.B noch viele Unterordner nutzt...

Zitat von Mokka123

Vor der aktuellen Version hat es die Position auf Nummer 80 gehalten. Ich hoffe, es war nun verständlicher was ich meine.

Er hat recht. Hier in der 102ESR kann ich das "alte" Verhalten bestätigen: Die Scrollposition wird gemerkt und bleibt bei einem nochmaligen Aufruf erhalten.

In der aktuellen Release-Version ist das nicht mehr der Fall. Ob das nun von Mozilla bewusst neu gestaltet wurde, oder ob dies ein Bug ist, kann ich nicht sagen...

Zitat von 2002Andreas

Das ist und war hier schon immer so.

Komisch, ich kann das vom Threadstarter beschriebene Verhalten in der ESR bestätigen...

Also bleibt es dann doch beim Filtern, da das ja überall funktioniert.

Hab mir 'Clippings' jetzt mal testweise installiert.

Zitat von 2002Andreas

da funktioniert nur dieser Code hier:

Ja, scheint so zu sein, da Im 'svg' für fill/stroke -> context-fill/context-stroke gesetzt sein muss.

Falls es dafür nicht auch eine einfachere Lösung gibt, nutzt man halt wahlweise das eine oder andere...

Zitat von 2002Andreas

Z.B. bei einem Icon einer Erweiterung, funktioniert die andere Version hier nicht

Hast du mal ein Beispiel?

Zitat von jane

So geht das:

Sehr schön, entfällt das doch recht umständliche "Gefiltere":

filter: invert(13%) sepia(68%) saturate(7447%) hue-rotate(1deg) brightness(103%) contrast(117%);

Zitat von .DeJaVu

Kannte ich zuletzt nur noch für die Ordnersymbole fur Aris css, mal schauen, ob noch genutzt hier. Danke.

Verdammt, Mist, stimmt! Das hatte ich ja gar nicht auf dem Schirm. Da kommt es ja "hundertfach" vor. Ich benutze noch eine relativ alte Version, muss jetzt auch mal bei Aris schauen, ob das immer noch so ist, oder ob sich da schon was getan hat...

Zitat von Sören Hentzschel

Laut Suchfunktion wird das hier immer noch teilweise in individuellen Anpassungen verwendet.

Das wir dann (laut Suchfunktion) in erster Linie wohl mich betreffen. Ist bei mir aber schon vor geraumer Zeit raus geflogen, da ich meine "Icon-Buttons" jetzt vollkommen anders handhabe. Danke für die Info!

Beitrag

RE: Toolbar-Icon für Add-on hat falsche Größe...

Ok, dann ist das Problem also schon bekannt. Danke für die Info!

Hoffe nur, dass es das Icon dann auch wieder mit 16x16 definiert wird, da ich in der userChrome.css '-moz-image-region' verwende um das Icon beim Aktivieren des Buttons in der Größe zu verändern ( 'scale' würde zusätzlich auch den Hintergrund skalieren ) und ich dann extra für den Add-On-Button eine neue Regel bräuchte...

BrokenHeart

31. März 2020 um 21:57

Zitat von Sören Hentzschel

Ausgehend von den Screenshots trifft das auf drei der fünf Duplikate nicht zu und ein Duplikat hat gar keinen Screenshot.

Stimmt.

Ich hatte mir nicht die letzten Duplikate angeschaut, da sind dann wirklich die gleichen Symptome zu erkennen.

Beim ersten Link zur "Brady Bunch"/"Arial Bold"-Thematik und den Screenshots waren es eben nur die Metriken...

Zitat von Sören Hentzschel

Und hängt demnach mit mehreren installierten Schriften zusammen, welche intern den gleichen Namen verwenden. Wenn nicht bewusst zusätzliche Schriften installiert wurden, dann vielleicht durch andere Software.

In den "several bugs", welche in dem verlinkten Bug zusammengefasst sind, geht es aber um Metriken, was auch die Screenshots zeigen. Die Texte sind allesamt noch lesbar, was in dem hier vorliegenden Fall ja nicht mehr gegeben ist.

Außerdem hatten wir auch schon einige Fälle (Link müsste ich suchen) unter Windows 7, komischerweise keine unter Win 10/11.

Wirklich schade, dass sich die Betroffenen hier im Forum alle nicht mehr weiter zu ihrem Problem geäußert haben...

Neben dem Screenshot vom 'Windows Error Reporting' wären die beiden darunter liegenden Fehlermeldungen mit den Ereignis-IDs 1000 und 1026 noch interessant. Die Windows-Managment-Konsole scheint abgestürzt zu sein. Aber ob dies die Ursache für das Beenden des Firefox ist oder Folge eines anderen Absturzes, lässt sich mit den wenigen Informationen nicht ermitteln.

Ist dieser Fehler jetzt zum ersten Mal oder schon öfters in der Vergangenheit aufgetreten?

Wurden noch andere Applikationen zeitgleich beendet?

Bitte auch unter "about:crashes" im Firefox nachschauen, ob da zeitgleich eine Absturzmeldung vorliegt...