Hallo zusammen,
seit FF 92 lässt sich die Suchleiste unten, die erscheint, wenn man mit Strg+F ein Wort auf der aktuellen Webseite suchen möchte, nicht mehr wie zuvor entfernen, weil das Kreuzchen dazu, das zuvor immer ganz rechts erschien, nicht mehr vorhanden ist. Ist das ein Bug oder ein "Feature"? 
Hallo Sören,
beim Sichten betroffener Websites stellte ich fest, dass diese per .htaccess Passwort-geschützt sind (Webalizer Webhosting-Statistiken und andere Administrations-Funktionen in Unterordnern, deren Zugangslinks ich lieber nicht veröffentlichen möchte, um keine Hacker anzuziehen).
Bis vor kurzem erschien zu den entsprechenden Bookmarks dennoch das Favicon der jeweiligen Homepage (beim Bookmark der Homepage funktioniert es auch weiterhin), jetzt stattdessen nur noch ein grüner Kreis mit einem weißen, nicht leserlichen Signet darin.
Hallo zusammen,
bei einigen Favoriten wird das Favicon der jeweiligen Seite nicht aktualisiert. Selbst ein Löschen des Favoriten und anschließende Neuanlage, Neuladen der Seite mit Shift+Aktualisieren usw. hilft leider nicht. Im Tab mit der jeweiligen Seite erscheint das Favicon korrekt, nicht aber im Lesezeichen-Menü und in der dazugehörigen Sidebar.
Gibt es hierzu eine Abhilfemöglichkeit?
Schau Dir mal die Erweiterung Don't track me Google an.
Dieses Addon funktioniert genau wie gewünscht, ist mit nur 25 KB winzig klein, benötigt nur den Zugriff auf abgerufene Google-Domains und wird von Firefox empfohlen, so dass es vertrauenswürdig sein sollte - top, danke!
Hallo zusammen,
seit einer Weile sind Links aus Google-Suchergebnissen - zumindest mit Firefox - kaum noch ohne Zusatzaufwand herauskopierbar, da Google ums Verrecken tracken will und alle Links mit einem eigenen Tracking versieht.
Bei einer Google-Suche nach "Firefox" (https://www.google.com/search?q=firefox) wird so aus dem ersten Treffer
zum Beispiel:
Seltsam: Beim ersten Mouseover erscheint zumindest im Firefox noch die letztendliche Ziel-URL, wenn man draufklickt, geht es aber über http://www.google.com/, und geht man dann zurück zur Google-Ergebnisseite, erscheint dann auch beim Mouseover sofort die Google-URL. Und geht man direkt per rechte Maustaste auf "Link-Adresse kopieren", wird auch sofort die Google-URL kopiert, und auch dann erscheint beim nächsten Mouseover dann diese.
Man muss also nun immer den URL-Parameter manuell aus der Google-URL herausschneiden, und dessen URL-Codierung dann auch noch irgendwie rückgängig machen?
Ziel von Google wird sein: Man soll keine Links auch Suchergebnissen mehr weiterleiten oder anderweitig verwenden, sondern stattdessen "Suche bei Google nach Firefox", damit Google jedes Mal neu wieder Anzeigen vermarkten kann? Die tun wirklich alles, um ihr Monopol knallhart auszuquetschen wie eine Zitrone.
Interessant ist, dass in Googles eigenem Browser Chrome die tatsächliche Ziel-URL kopiert wird und nicht die Google-Tracking-URL. Ob Mozilla hier nachziehen kann?
Das Performance-Problem ließ sich zwischenzeitlich mit einer serverseitigen Änderung der Caching-Vorgaben lösen.
Ganz konkret war in punkto Caching übrigens zumindest beim hier verwendeten Hoster der Knackpunkt, dass Apache 2.4 den MimeType "image/webp" standardmäßig noch nicht kannte, so dass man ihn vor einem etwaigen Expires-Kommando z.B. im .htaccess erst selbst ergänzen muss:
AddType image/webp .webp
ExpiresByType image/webp "access plus 1 week"Tatsächlich, die Anführungszeichen machen den Unterschied. Auch wenn die Argumente in CSS anderswo auch ohne sie funktionieren, funktioniert type() innerhalb von image-set nur mit Anführungszeichen (egal ob ein- oder zweistrichig) zwischen den Klammern. Dankeschön!
Jetzt bleibt zu hoffen, dass Chrome, Edge usw. das type()-Argument in image-set auch bald berücksichtigen, am besten auch ohne das Präfix -webkit-.
Das Performance-Problem ließ sich zwischenzeitlich mit einer serverseitigen Änderung der Caching-Vorgaben lösen.
Auch FF 90 ignoriert image-set allerdings, sobald man dabei das type-Attribut verwendet. Code-Beispiel:
<table><tr>
<td style="background-image:url(bgpic_fallback1.png); background-image:image-set(url(bgpic.webp) type(image/webp), url(bgpic_fallback2.png) type(image/png));">
</tr></table>Hier wird leider stets bgpic_fallback1.png verwendet.
Ohne type lässt sich für per CSS eingebundene background-images allerdings kein Fallback realisieren.
Hallo zusammen,
u.a. Google empfiehlt, bei Bildern das "next generation format" WEBP statt z.B. GIF, JPG oder PNG zu verwenden. Tatsächlich verringert das Format die Dateigröße meiner Erfahrung nach je nach Motiv um 20-80%, und mit bloßem Auge sind die geringfügigen Unterschiede bei verlustbehafteter Komprimierung kaum zu sehen.
Da noch nicht alle Browser WEBP unterstützen, ist man darauf angewiesen, ein altes Format (GIF, JPG oder PNG) als Fallback vorzuhalten. Dazu gibt es das HTML-Tag <picture> sowie in CSS image-set.
Probleme:
1. WEBP-Bilder werden trotz Caching zumindest im Firefox im Vergleich zu den anderen Formaten mit leichter zeitlicher Verzögerung dargestellt, was auch mit bloßem Auge auffällt, wenn z.B. auf einer Seite verschiedene Formate zusammen auftreten. Die GIFs, JPGs und PNGs erscheinen immer alle zeitgleich, bevor dann kurz darauf die WEBPs folgen. Das ist schade, weil das WEBP in meinem Fall 80% der Dateigröße einspart, aber trotzdem im Vergleich zu den anderen (deutlich größeren) Formaten verzögert angezeigt wird. Ist das WEBP-Rendering derzeit ggf. noch nicht ganz optimal und wird noch genauso schnell wie bei GIF, JPG und PNG?
Edit: In Microsoft Edge tritt die kleine Verzögerung bei der Anzeige von WEBPs übrigens so nicht auf. Allerdings werden die WEBPs dort seltsamerweise nicht gecacht (im Firefox dagegen schon), obwohl vom Webserver alle vier Formate dafür vorgesehen sind.
2. <picture> funktioniert einwandfrei, aber image-set in CSS (z.B. für Hintergrundbilder benötigt) unterstützt in den gängigen Browsern tatsächlich das type-Attribut noch nicht, obwohl es bereits dokumentiert ist: https://developer.mozilla.org/en-US/docs/Web/CSS/image/image-set()
Sobald man im image-set eine url mit type ergänzt, wird das ganze image-set nicht mehr berücksichtigt, und der Fallback auf das vorangestellte "background-image: url" ohne image-set greift. Ist hier schon etwas dokumentiert, was tatsächlich im Browser noch nicht funktioniert?
Es muss doch hier bei einer Frage, ob es bei anderen genauso ist, niemand antworten. Sondern nur die, die vielleicht zufällig die gleiche Konstellation haben. Gibt's manchmal nicht? Dann ist es halt so.
Du und vielleicht noch ein paar andere hier haben aber den Anspruch, auf jedes Thema selbst antworten zu müssen und unbedingt etwas tun zu müssen. In vielen Fällen helft Ihr bestimmt auch, gar keine Frage. Manchmal erschwert dieser innere Anspruch es aber auch, weil nicht jeder Fragesteller so weit gehen möchte, sondern einfach nur andere Betroffene sucht. Dafür gibt's dann "Schimpfe".
Aber letztlich: Es ist Dein Forum, nicht meins. Daher machst Du es letztlich, wie Du es für richtig hältst. Das passt schon.
Es mag sein, dass es sich bei 90% der Fragesteller hier um "Dummies" handelt bzw. der Fehler eher beim User liegt. Bei meinen gelegentlichen Software-Problemen ist es dagegen erfahrungsgemäß anders herum, d.h. in 90% sind es Bugs (oder seltener "it's not a bug, it's a feature"-Fälle ).
Worauf ich hinaus möchte: Als allererstes immer ein kurzer Check, ob andere das gleiche Problem haben (hätte ich allerdings auch selbst früher als in #23 ganz konkret so erfragen können: RE: Firefox stürzt gelegentlich ab, eventuell Zusammenhang mit Kee-Addon?), macht doch in jedem Fall Sinn, bevor man Helpline-Mechanismen startet, die allen Seiten deutlich mehr Arbeit bereiten?
Da es im verlinkten, anderen Forum im Gegensatz zu hier so dermaßen unkompliziert klappte, möchte ich nur noch einmal um Verständnis für meine generelle Vorgehensweise bitten: Ich versuche immer zuallererst, zu checken, ob andere das gleiche Problem haben:
- Wenn ja, deutet das (natürlich nicht absolut zwingend, aber wahrscheinlich) auf einen Bug hin, so dass die Sache ganz schnell gegessen ist und man nur die nächsten Updates abwarten oder bestenfalls den Hersteller darauf aufmerksam machen kann.
- Wenn nein, kann man ggf. den erheblich mühsameren Weg gehen, andere mit haufenweise Daten füttern, die dann eventuell verschiedene Vorschläge machen, was man alles probieren könnte. Damit verliert man bestenfalls viel Zeit, schlimmstenfalls zerschießt man sich dabei auch noch unbeabsichtigt sein System.
Glaubt mir: In 90% der Fälle handelte es sich zumindest in meiner Historie um Bugs oder Dinge, die halt so sind und an denen man nichts ändern kann. Macht es da wirklich Sinn, die paar Minuten Check, ob es anderswo auch so ist, immer zu überspringen und sofort stundenlang zu experimentieren und zu probieren? Das kostet doch den Fragesteller als auch die Antwortenden nur viel Zeit, die sich alle mit einem simplen Vorab-Check, ob es bei anderen genauso ist, sparen könnten. Ist dieser Gedanke für Euch hier so abwegig?
Der Entwicker des Kee-Addons, luckyrat, hat doch glatt einfach selbst die besagte Website geöffnet, dann kurz Keepass geöffnet und den Bug reproduzieren können
Und siehe da, er scheint zumindest ein Bugfix gefunden zu haben, dessen Erscheinen sich aber durch den Release-Prozess wohl noch etwas verzögert:
https://forum.kee.pm/t/kee-browser-…-is-opened/3518
Es scheint mit durch das Addon zu umgehenden Bugs im Firefox, SVGs und einem in die besuchten Websites injizierten Start-Script zu tun zu haben.
Oder ich probiere es eventuell mal mit KeePassXC. Das ist zwar kompatibel mit KeePass und "nur" ein Fork, aber vielleicht gibt es den Bug mit dessen eigenem Firefox-Addon nicht?
Habe nun noch weiter selbst getestet (mit FF 85.0.1, Addons automatisch aktualisiert):
- Alle Addons deaktiviert, außer Kee-Addon für KeePass
- Sobald https://www.ariva.de/aktien/ offen ist und dann KeePasss gestartet wird, entsteht im FF hohe CPU-Last (50-90%), und der Speicherbedarf steigt rasant an.
- Dies passiert leider reproduzierbar immer.
- Wenn andere Seiten offen sind und nicht Ariva, lässt sich KeePass ganz normal ohne besagte Probleme öffnen.
Ist das bei Euch auch so bzw. bei Euch nicht so?
Aber da sind ja lauter private Daten drin, die nicht öffentlich in einem Forum stehen sollten?
Soeben trat der Fehler erneut auf: Firefox ist geöffnet, nur zwei Tabs. Ich öffne KeePass und gebe mein Passwort dort ein, währenddessen Firefox mit installiertem Kee-Addon lt. Task-Manager auf 50% CPU-Last ansteigt, er kaum noch reagiert und der Speicherbedarf sekündlich stark ansteigt. Als ich KeePass daraufhin wieder beende, normalisiert sich die CPU-Last langsam über ca. 10-20 Sekunden wieder gegen Null. Unter about:crashes gibt es keinen neuen Eintrag (es war ja auch kein "richtiger" Crash). Kurz darauf öffne ich KeePass erneut, und nun funktioniert es ganz normal ohne stark erhöhte Last.
Weitere Erkenntnisse:
- Der Fehler tritt reproduzierbar auf, wenn die Finanzseite http://www.ariva.de geöffnet ist und ich dann KeePass öffne (schon vor der dortigen Passworteingabe).
- Schließe ich dann KeePass, bleibt die Last bestehen.
- Schließe ich den Tab mit http://www.ariva.de, verschwindet die Last nicht sofort, aber wie gesagt nach ca. 10-20 Sekunden.
Gib uns mal bitte Infos zu deinem Firefox und deiner verwendeten Sicherheitssoftware.
--> Hilfe --> Informationen zur Fehlerbehebung .. dann den Text in die Zwischenablage (Button) kopieren und hier mittels des Code-Buttons </> hier im Forum posten. (siehe dazu)
Zudem gebe bitte mal about:crashes in die Adressleiste ein und klicke dann die letzten drei, vier Crash-Reports an. Die URL von den neuen Tabs mit den Reports dann bitte hier posten.
Sicherheitssoftware: Nur Windows Defender
Addons: uBlock Origin, uMatrix, Cookie AutoDelete, Firefox Multi-Account Containers, Kee
Welche besonderen Dinge machst du, wenn das passiert? Beispielsweise das Ansehen von Videos, die Verwendung von Entwicklerwerkzeugen, …
Gibt es einen Grund, dass du KeePass verdächtigst? Ist dir irgendetwas in Zusammenhang damit aufgefallen?
Eigentlich nichts, was mir besonders auffiel. Meistens war nur noch ein Tab offen mit einer sehr einfachen Seite, nachdem ich - und hier meine ich zumindest grob aus der Erinnerung, eventuell ein Muster zu erkennen - vorher eines von mehreren Kundenportalen z.B. von Stromversorgern o.Ä., zu denen ich mit mit KeePass per Kee-Addon einlogge, beendet und den Tab geschlossen hatte.
Dankeschön, habe "Firefox erlauben, Daten zu technischen Details und Interaktionen an Mozilla zu senden" nun aktiviert. Stimmt, solange keine persönlichen Daten dabei versendet werden (außer vielleicht der IP, wie beschrieben), macht das natürlich Sinn.
Werde dann nach dem nächsten Hänger bzw. harten Beenden per Task-Manager wieder unter about:crashes nachschauen und das Ergebnis hier posten.
