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.
Danke für Eure Antworten und Rückfragen. Leider ergibt about:crashes nur 3 nicht gesendete Absturzberichte von 2018 und "Es wurden noch keine Absturzberichte versendet". Liegt das eventuell daran, dass in den Einstellungen "Datenerhebung durch Firefox und deren Verwendung" deaktiviert ist bzw. was genau muss für die Absturzberichte aktiviert werden?
Hallo zusammen,
seit ein paar Wochen stürzt Firefox vermehrt gelegentlich ab (zuvor nie): Erst läuft alles eine Weile ganz normal, dann plötzlich annähernd 100% CPU-Last und schnell zunehmende Speicherbelegung von vielen GB (!) RAM durch 1-2 FF-Tasks. Der FF reagiert dann kaum bis nicht mehr, und man kann ihn nur noch über den Taskmanager hart beenden.
Eventuell gibt es einen Zusammenhang mit dem Kee-Addon (für KeePass), dies konnte ich aber noch nicht ausreichend genau beobachten. Ist dazu eventuell jemandem etwas bekannt?
Hallo zusammen,
seit wenigen Tagen erhalte ich bei der Nutzung der in Firefox integrierten Google-Suche, bei der dann zu google.com gesprungen wird, regelmäßig ein Cookie-Popup von Google. Über uMatrix habe ich google.com für Scripting gesperrt, so dass sich Google die Auswahl dann nicht merkt und diese dann immer wieder erscheint. Kann ich die Google-Suche im Firefox irgendwie so einstellen, dass sie über google.de statt über google.com läuft?
Der erscheint seit FF 73 leider immer mittig und in fixer Größe (zuvor dort, wo er zuletzt hin verschoben wurde, in der dann eingestellten Größe).
Das ist ein 'Bug' in der aktuellen Version. Keine Ahnung, ob es da schon einen Bugzilla-Eintrag zu gibt. In der Nightly (FF76) merkt er sich wieder die letzte Position.
Herzlichen Dank für die Aufklärung!
Dann kann ich den CSS-Hack, der zumindest die Größe - wenn auch fix - nach Wunsch verändert (Lesezeichen editieren: Seit FF 73 wird Fenstergröße nicht mehr gespeichert, Workaround?) ja ab FF 76 wieder entfernen!
Seit dem heutigen Update auf FF 76 merkt sich Firefox Position und Größe des Dialogs für die Lesezeichen-Eigenschaften wieder!
Interessanterweise auch ohne die Entfernung der o.g. fixen Größeneinstellung aus dem CSS, diese wird seit FF 76 offenbar ignoriert. Hab sie trotzdem wieder entfernt.
Mir fiel noch auf, dass die Internetverbindung (Telekom) kurz vorher neu aufgebaut und dadurch eine neue IP-Adresse vergeben wurde (natürlich ebenfalls aus der Range der Telekom), was alle paar Monate mal geschieht. Aber dann deshalb eine gute Woche lang (statt einmalig) jedes Mal der zweite Faktor SMS-Code? Ob das der Grund war - man könnte spekulieren.
Bei Google Ads habe ich die Sache längst moniert, allerdings weiß man dort (wie leider so oft bei Kundensupport-Hotlines...) nicht weiter und flüchtet sich in nicht hilfreiche Textblöcke ("es könnte an dies und jenem liegen, prüfen Sie dies und prüfen Sie jenes, ..." - alles längst gemacht). "Hands-On" und eine konkrete Überprüfung sind auch dort wie immer nicht möglich.
Heute übrigens erfolgt die zusätzliche Abfrage des per SMS zugesandten Google-Codes plötzlich nicht mehr, ohne dass ich etwas verändert habe.
