Ich bin nun alle Tipps aus folgender FF-Hilfeseite durchgegangen:
https://support.mozilla.org/t5/Firefox-ist…Last/ta-p/15387
- FF-Update auf 52
- Abgesicherter Modus ohne Erweiterungen und Plugins
- Hardwarebeschleunigung aktiviert
- content-prefs.sqlite gelöscht
Trotzdem verursacht Amazon bei mir weiterhin stark erhöhte, dauerhafte CPU-Last, z.B. die Angebote (https://www.amazon.de/gp/angebote/) dauerhaft um die 10%. Das kann doch nicht normal sein?
Im abgesicherten Modus ohne Add-Ons und nach dem Update von FF 51 zu 52 ändert sich das Problem übrigens nicht, auch da die dauerhafte, erhöhte CPU-Last.
andreas: Meine FF-App hat auch fast 0%, allerdings nicht der FF-Hintergrundprozess:
[attachment=0]scr_ff.png[/attachment]
Könnte das auch mit NoScript zusammenhängen? Die von den Amazon-Seiten benötigten Scripting-URLs sind darin allerdings alle freigeschaltet.
Die Last in Amazon Seller Central verursachen lt. Laufzeitanalyse im FF "Stil-Neuberechnung / CSSAnimations". Seltsamerweise aber nicht mit anderen Browsern wie Chrome, nur mit FF.
Übrigens erzeugt auch die ganz normale Amazon-Angebote-Seite dauerhaft ca. 15% CPU-Last, hier durch "setInterval":
https://www.amazon.de/gp/angebote/ref=nav_cs_gb
Amazon lässt sich so kaum noch nutzen, weil immer gleich der Lüfter startet und nicht mehr still steht, bis man die Seite wieder verlässt.
Ich das ein Programmierfehler bei Amazon oder eine Inkompatibilität von FF?
Warum soll das denn nicht normal sein? Ein beschäftigter Browser beansprucht natürlich die CPU, vor allem wenn Webseiten offen sind, die eben nicht nur aus statischem Text bestehen…
Die Seite besteht aber nur aus statischem Text, und bei anderen Seiten nur mit statischem Text sinkt die FF-CPU-Last i.d.R. zügig gen 0-2%.
5% dauerhafte CPU-Last durch FF sind ja auch schon unnormal.
Noch was: Ohne weitere Systemveränderungen war es vor FF 51 nicht so, ab FF 51 dann schlagartig.
Hallo zusammen,
seit Firefox 51 erzeugt Amazon Seller Central (https://sellercentral.amazon.de/gp/homepage.html) dauerhaft hohe CPU-Last - schon auf der Homepage nach dem Login ca. 5%, und in der Lagerbestandsansicht ca. 30%.
Ich vermute, hier hat sich etwas an der Scripting-Engine geändert, und irgendetwas läuft hier in den roten Bereich?
Ich finde das Verhalten von FF bei der GLS-Paketshopsuche (https://gls-group.eu/DE/de/depot-paketshop-suche), die funktioniert, wenn man Cookies erlaubt mit der Option "bis sie nicht mehr gültig sind", die aber nicht funktioniert, wenn man Cookies erlaubt mit der Option "jedes Mal nachfragen" (und dann erscheint auch gar keine Nachfrage), definitiv fehlerhaft. Denn das ist doch unlogisch. FF müsste wenigstens nachfragen, man klickt zum benötigten Cookie auf "OK", und that's it. Funktioniert aber so nicht. Man stellt mit dieser Option folglich offenbar mehr um, als es logisch wäre.
Generell finde ich die FF-Änderungen hinsichtlich Cookies auch praxisuntauglich: Warum kann man nicht mehr, wie es bis vor einiger Zeit möglich war, z.B. alle Cookies von xyz.de freischalten, sondern muss nun http://xyz.de, http://www.xyz.de, http://sub1.xyz.de, http://sub2.xyz.de, https://xyz.de, https://www.xyz.de, https://sub1.xyz.de, https://sub2.xyz.de usw. alles selbst erraten und freischalten? Das mag sicherer sein, aber praktisch oft nicht mehr handhabbar.
Der Entwickler der o.g. Website teilte mir mit, dass der "Garbage Collector" des Firefox das Problem sei, weil er voll laufe, den Speicherbedarf stark erhöhe (was sich bei mir bestätigt - der Speicherbedarf des FF steigt mit laufender Website quasi sekündlich an und steht schnell z.B. von 135 auf 220 MB) und dadurch wohl auch die CPU-Last erhöhe. Mit Google Chrome gäbe es das Problem wohl nicht.
Da bin ich damals u.a. extra wegen der deutlich geringeren CPU-Last bei Scripten vom MSIE zum FF gewechselt, und nun hat auch dieser hier ein Problem. Muss ich jetzt wirklich weiter zu Chrome wechseln? Eigentlich mag ich den FF nach anfänglicher Skepsis und einigen Zipperlein auch wegen NoScript mittlerweile sehr gern. Oder ist das Garbage-Collector-Problem nur temporär und wird beim nächsten Update gelöst?
Hallo zusammen,
seit Version 43.0.4 erzeugt FF bei Scripten scheinbar leicht erhöhte CPU-Last. Mir fiel diese auf, weil ich eine (unveränderte) Website quasi ganztags offen lasse, die sich in Abständen von ca. 5-10s selbst aktualisiert. Die regelmäßigen Refreshs verursachen im Leerlauf jedes Mal kurz 10-15% Auslastung. Das reicht leider aus, um meinen Lüfter, der sonst permanent aus ist, nun plötzlich permanent laufen zu lassen. Unabhängig davon schaffen es auch Seiten mit umfangreicheren Scripts wie diverse Google-Seiten mit Tabellen und diversen Funktionen, die Last so zu steigern, dass der Lüfter lange anspringt. Bis FF 43.0.0 war dies nie so.
Hat sich die Scripting-Engine in 43.0.4 irgendwie in diese Richtung verändert? Denn die extrem niedrige Last auch bei Scripten war eigentlich eine der USPs für Firefox (während der MSIE zuvor eine noch viel höhere Last erzeugte).
Dass ABP nicht alles erkennen kann, ist schon klar. Nur: Warum erscheinen die Banner ohne ABP nicht (scheinbar, weil externe Scripte wg. NoScript nicht ausgeführt werden), mit ABP bei ansonsten unveränderten Einstellungen (auch bei NoScript) hingegen schon, d.h. setzt ABP teilweise NoScript außer Kraft?
Hallo zusammen,
auf einigen Websites blendet AdBlock Plus tatsächlich Banner aus.
Auf einigen anderen aber, wie z.B. auf der Finanzseite ariva.de, erscheinen, wenn man in NoScript nur ariva.de und keine 3rd-Party-Domains freigibt, ohne AdBlock Plus keine Banner oben und rechts, mit unverändertem NoScript und aktiviertem ABP dagegen erscheinen die Banner plötzlich, und wenn man sie per eigenem Filter manuell ausblendet, ändert das daran nichts und sie erscheinen weiter.
Wie kann das denn sein, ABP soll doch Banner ausblenden und nicht sowieso schon auf anderem Wege ausgeblendete Banner wieder hervorholen?
Hallo zusammen,
wie ich in den Bewertungen der Erweiterung "Cookie Monster" las, gibt oder gab es Probleme mit FF ab 37 und 42.
Sind diese mit FF 43 passé oder wurde Cookie Monster zwischenzeitlich angepasst, oder herrschen die Probleme immer noch vor (Mozilla hat das Add-On offenbar nicht nicht wieder signiert)?
Nachdem ja "jedes Mal nachfragen" als Ersatz für "bis sie nicht mehr gültig sind" leider nicht taugt, da es zwischen den beiden Optionen offensichtlich mehr Unterschiede gibt, als man es denken sollte und als es logisch wäre, mal die Frage: Gibt es empfehlenswerte Cookie-Management-Add-Ons für FF, die FF diese Aufgabe abnehmen und sie besser lösen, z.B. in NoScript-Manier mit einen auf die aktuelle Website bezogenen Kontextmenü, in dem man die beabsichtigten Cookies sieht und diese dann einzeln freigeben oder sperren kann?
Hallo zusammen,
das ist allerdings seltsam: Den Unterschied macht es, ob ich Cookies aktiviere oder nicht.
1. Und das, obwohl ich die URLs für die gesetzten Cookies (d.h. alle Cookies, die lt. Cookie-Liste bei aktivierten Cookies von der GLS-Website gesetzt werden) in der Ausnahmenliste explizit freigegeben habe.
2. Selbst wenn ich Cookies generell freigebe, reicht "jedes Mal nachfragen" (s. Screenshot, Mitte) nicht, sondern man muss Cookies bis in alle Ewigkeit freigeben (s. Screenshot, oben) - obwohl es doch eigentlich keinerlei Unterschied machen dürfte, ob ich Cookies generell vorab freigebe oder dies einzeln per Alert vornehme. Es kommen dann auch keine Abfrage-Alerts - und blockiert ist in den Ausnahmen auch nichts.
Kann sich dieses seltsame Verhalten noch jemand erklären?
Die Signatur ist nicht ganz wörtlich zu nehmen. Ich möchte damit nur das Aufzwängen von "Totschlag-Herangehensweisen" vermeiden, wie ich es hier schon öfter mal von Usern mit sehr vielen Postings erlebte. Das Thema wurde aber andernortens schon ausdiskutiert und soll hier nicht mehr Thema sein.
Falls also noch jemand eine hilfreiche Idee zu Posting #21 hat, feel free 
PS: Frohes neues Jahr!
Danke für diese hilfreiche Info zu diesem (Neben-)Thema, Sören!
Zwischenzeitlich habe ich auf dem Zweit-PC experimentiert (auf dem Produktivsystem vermeide ich dies stets, so weit es geht):
- Mit einem neuen Profil funktioniert die GLS-Paketshop-Suche.
- Auch wenn ich NoScript dann auf das neue Profil nachinstalliere und die URLs für die Paketshopsuche dort freigebe, funktioniert sie weiter.
Der Knackpunkt ist dagegen folgender: FF-Einstellungen -> Datenschutz -> Chronik
- Solange ich hier "anlegen" ausgewählt lasse, funktioniert es.
- Wähle ich hier aber (und so hatte ich es bisher immer) "nach benutzerdefinierten Einstellungen anlegen", funktioniert die Paketshopsuche schlagartig nicht mehr. Seltsamerweise selbst dann nicht, wenn ich die dann darunter erscheinenden Optionen alle unverändert belasse, also u.a. "Cookies akzeptieren" (s. Screenshot).
Auf meinem Produktivsystem bestätigt sich dies: Auch ohne neues Profil muss ich hier nur unter FF-Einstellungen -> Datenschutz -> Chronik "anlegen" auswählen, und die Paketshopsuche funktioniert.
Kann sich das jemand erklären? Chronik "anlegen" und "nach benutzerdefinierten Einstellungen anlegen" sollten doch eigentlich identisch sein, solange man die dort erscheinenden Einstellungen dann nicht selbst verändert.
Generell möchte ich zudem eigentlich weiterhin Cookies nicht akzeptieren und diese bei Bedarf als Ausnahme eintragen. Denn sonst trackt mich doch Gott und die Welt.
Road-Runner und AngelOfDarkness: Bitte meine Signatur beachten
Könnte vielleicht mal jemand auf das eigentliche Thema des Threads (DOMException [SecurityError: "The operation is insecure.") eingehen? Denn da liegt doch scheinbar Website-seitig etwas im Argen.
Übrigens wird auf einem ganz anderen System (Zweit-PC) als neuestes Update auch nur FF 43.0.1 installiert. Aber vermutlich liegt das GLS-Paketshop-Problem ja auch gar nicht daran. Mit MS Edge erscheint die GLS-Paketshopsuche auf jenem System korrekt, mit FF leider ebenfalls nicht.
