Beiträge von Derman

Boersenfeger
Ja, ein solch iteratives Vorgehen hatte ich auch im Sinn (und hab's probiert, war aber für die obligatorischen 5 min zu viel), das kostet aber einige Stunden (bis Tage), die im Moment nicht zur Verfügung stehen. In Verbindung mit dem, was ich am Mi., 16.10.2019, 06:04, geschrieben hatte, nämlich eine Phantomjagd vermeiden zu wollen, folgender Vorschlag: Ich vergesse dieses Thema nicht und werde mich dazu in etwa 3 Wochen mit weiteren Resultaten melden.

StandingBill: Hhmm, wie wär's mit dir /on /s?

Zitronella: Dies bestätigt meine Beobachtung, siehe mein Bild https://www.camp-firefox.de/attachment/223…11-285-001-png/. Und die Datei parent.lock dürfte dort nicht sein, vergleiche
Erledigt....parent.lock wird beim Beenden nicht gelöscht
https://www.thunderbird-mail.de/forum/thread/3…k-l%C3%B6schen/
https://www.pcmasters.de/forum/threads/…nix-mehr.94913/
https://rzotrs.rz.tu-bs.de/otrs/public.pl…dGFydEhpdD0x%0A;
Der Profilmanager von MZFF 68.0.2 arbeitet demnach korrekt.

Nicht um den heißen Brei herumschreiben, welche Datei, Name, Größe, in welchem Verzeichnis, eine Liste erstellen und in den Beitragstext hineinkopieren, ist schneller getan als der prosaische Text überlegt ist. (Hab' zwar schon länger nicht mehr nachgeschaut, aber ich meine: Bei der Neuinstallation wird kein Profil angelegt, erst beim ersten Start.)

Zitat von StandingBill

Das wäre höchst seltsam und ist - wie aus deinem weiteren Text hervorgeht - nicht korrekt.

Welche Dateien sollten denn in dem via Profilmanager neu erstellen Profilverzeichnis (%APPDATA%\Mozilla\Firefox\Profiles\<TheProfileDir>\) (Roaming) gespeichert sein? Wegen des initialen Zustandes macht viele keinen Sinn, dahingehend war ja auch dein Hinweis mit einem neuen Profil zu verstehen. Oder nicht?

Zitat von StandingBill

Das kann ebenfalls nicht sein.

Und welche Dateien sollten im zugehörigen Local-Verzeichnis (%LOCALAPPDATA%\Mozilla\Firefox\Profiles\<TheProfileDir>\) sein? Da dort Dateien zur Sitzung (cache) gespeichert werden, eine Sitzung aber noch nicht stattgefunden hat, braucht dort auch keine Datei sein. Oder nicht?

Zitat von StandingBill

Da es ansonsten funktioniert, würde ich die Sache auf sich beruhen lassen.

Hhmm, das klingt nach Augen zu und Weglaufen. Einerseits ja, um eine Phantomjagd zu vermeiden, denn jene prefs.js, mit der das Phänomen auftrat, ist nicht mehr exakt herstellbar, es waren zu viele Änderungen auf ein Mal. Andererseits nein, denn ein Ultimativum zur Abwärtsinkompatibilität und zu den Dateien in den Verzeichnissen fehlt noch, was dein Aktualisierungshinweis ja unterstreicht.

Es schaut so aus, als würde die Kombination der neuen Softwareversion mit der bisher verwendeten Datei prefs.js das oben beschriebene Phänomen (mit) verursachen:

• Via Profile Manager ein neues Profil angelegt:
  
  • Das Verzeichnis %APPDATA%\Mozilla\Firefox\Profiles\<TheProfileDir>\ enthält nur die Datei times.json (das wusste ich bereits) mit dem Inhalt {"created": 1571071268380,"firstUse": null} (firstUse wusste ich noch nicht)
  • Das Verzeichnis %LOCALAPPDATA%\Mozilla\Firefox\Profiles\<TheProfileDir>\ ist leer.
  • MZFF aus dem Profilmanager heraus gestartet und obige URLs aufgerufen: Keine Verzögerung.
• Das Ganze noch einmal, jedoch vor dem MZFF-Start die bisher verwendete Datei user.js in das Profilverzeichnis kopiert, erst danach obige URLs aufgerufen: Keine Verzögerung.
• Die durch MZFF im neu angelegten Profilverzeichnis generierte Datei prefs.js in das bisherige Profilverzeichnis kopiert, MZFF gestartet und obige URLs aufgerufen: Keine Verzögerung.

Welcher Eintrag in der Datei prefs.js könnte (mit) verantwortlich sein? Ich hab' zwar die Dateidifferenz zwischen vorher und nachher analysiert, hab' jedoch keinen Anhalt gesehen, woraus die Verzögerung sich hätte ergeben können (exakt die Version von vor einer Woche wieder herzustellen wird schwierig). Bei welcher passenden Stelle ist denn etwas über Abwärtsinkompatibilitäten zu erfahren, um diese dann bei den Konfigurationsdateien berücksichtigen zu können?

Hallo Allerseits!

Oft, aber nicht immer, dauert es ca. 12 s, bis Mozilla Firefox (MZFF) das Laden der Seite beginnt. Ist das noch jemandem aufgefallen? Ist das vielleicht durch eine Einstellung bedingt?

Die Situation genauer: FF ist gestartet, alles ist neu angelegt (startupCache; storage; ...), 1 Fenster, 1 Registerkarte, keine Last (CPU; Netzwerk; I/O). Aufruf einer URL, z. B. die zu diesem Thema. Es geschieht nichts. Erst nach ca. 12 s erscheinen links unten die bekannten Meldungen (Connect; Transfer; ...). Nach weiteren ca. 1,5 s ist die Seite komplett dargestellt.

So eine Verzögerungszeit tritt auch unverhofft auf. Bei der Recherche habe ich den Beitrag ``Wartezeit im Windows Explorer´´ (https://www.drwindows.de/windows-7-allgemein/55260-wartezeit-windows-explorer.html) gefunden. Die Seite wurde ohne Verzögerung geladen, ebenso das erste Bild (https://www.drwindows.de/attachments/70102d1340303458-wartezeit-windows-explorer-1.jpg) nach Linksmausklick auf die Miniaturansicht. Nach Linksmausklick auf die zweite Miniaturansicht daneben (https://www.drwindows.de/attachments/70103d1340303466-wartezeit-windows-explorer-2.jpg) wurde das Bild erst nach ca. 12 s Verzögerung angezeigt.

Folgendes konnte ich zwei Mal hintereinander reproduzieren, ab dem dritten Mal startete das Laden ohne Verzögerung:

- Neue Registerkarte geöffnet.

- Alle anderen Registerkarten geschlossen.

- Web Developer gestartet.

- URL https://www.google.de/ eingegeben, jedoch noch nicht abgeschickt.

- Performance aufgerufen.

- 0 ms: Performance gestartet.

- 4800 ms: URL abgeschickt (Enter).

- 16640 ms (11840 ms nach Enter): Function Call. Cause: Gecko.

Weitere URLs:

- https://dict.leo.org/german-english/: Das erste Mal verzögertes Laden (ca. 12 s), danach unverzögert.

- https://www.camp-firefox.de/forum/: Verzögert; unverzögert

- https://www.ebay-kleinanzeigen.de/: Verzögert; unverzögert

- https://www.ebay.de/: Unverzögert

- https://www.microsoft.com/de-de/: Unverzögert

- https://www.soeren-hentzschel.at/: Verzögert; unverzögert

- https://www.wikipedia.de/: Verzögert; unverzögert

Weitere Beispiele:

- Bei https://www.ebay-kleinanzeigen.de/ können eingestellte Bilder nacheinander zur Anzeige gebracht werden. Die ersten (z. B. 5) Bilder werden unverzögert dargestellt, ein nachfolgendes (z. B. das 6.) Bild wird ca. 12 s verzögert dargestellt.

- Bei https://dict.leo.org/german-english/ können nacheinander verschiedene Begriffe abgerufen werden, bei den ersten 1-2-3 (z. B.) geht es fix (ca. 1,5 s), beim 4. (z. B.) tut sich ca. 12 s lang nichts, danach ist die Seite nach weiteren ca. 1,5 s dargestellt.

Bei älteren Versionen (im allgemeinen) (und im speziellen 50.1.0, 59.0.2, 61.0.1, 64.0.2) wurde kein verzögertes Laden beobachtet. Bei den Release-Notes zu den Versionen 68.1.0 und 69.0 habe ich keinen Hinweis zu einer Verzögerungszeit gefunden.

Bei dem hier im Forum gefundenen Beitrag ``Geschwindigkeit´´ (https://www.camp-firefox.de/forum/thema/128582-geschwindigkeit/) geht es um das verzögerte Öffnen aller (!) Webseiten. Hier geht es jedoch um ca. 12 s ersteinmal nichts tun, und das bei nicht allen Seiten und bei nicht allen Anwendungsfällen.

OS: Windows 7 Professional 64-Bit. MZFF: 68.0.2 en-US EME Free. Extensions: Keine explizit installiert. Plugins: Keine explizit installiert. Themes: Nur Standard-Lightweight (z. B. firefox-compact-light@mozilla.org).

Danke!

MZFF 68.0.2
Datei user.js im Profilverzeichnis:

user_pref("datareporting.healthreport.documentServerURI", "");

user_pref("datareporting.healthreport.service.enabled", false);

user_pref("datareporting.healthreport.uploadEnabled", false);

user_pref("datareporting.policy.dataSubmissionEnabled", false);

user_pref("datareporting.policy.dataSubmissionEnabled.v2", false);

Im Profil-Verzeichnis datareporting ist dann nur die Datei state.json mit dem Inhalt {"clientID":"12345678-1234-1234-1234-123456789012"}.