auch der Fx 60 ESR startet nicht minimiert.
Dann liegt es wahrscheinlich an den ganzen Tor-Modifizierungen. Es dauerte relativ lange, bis die Quantum-ESR-Version damit ohne Probleme lief.
Alf aus Mannheim
ESR bedeutet "Extended Support Release". Diese Version wurde für Unternehmen konzipiert und hat längere Updatezyklen. Sie ist aber auch für den privaten Bereich nutzbar.
Gruß, Nobby
Werde ich machen, möchte aber vorher noch auf andere Meinungen warten, um sicher zu sein, dass es sich nicht um irgendeine FF- oder Windowseinstellung handelt, die bei mir den minimierten Start verhindert.
Vor allem würde mich interessieren, ob's anderen auch so geht und ob sie das stört/ärgert.
Hallöchen, keine aktuelle Firefox-Version (Release, Beta, Nightly) startet hier minimiert (Windows 7 Pro 32-bit). Auch wenn das in den Verknüpfungen so eingestellt ist, kommt ein Fenster. Nur der Tor-Browser 8.0, der auf dem Firefox 60.0.2 ESR basiert macht das. Vielleicht probierst Du mal die aktuelle ESR? Ich habe diese Lösung bisher noch nie gebraucht und es heute zum ersten Mal ausprobiert.
Google Chrome startet z.B. minimiert, aber ich habe dann nach dem Öffnen des Fensters schwarze Flächen drin, die da nicht hingehören. Der einzige Browser, der hier ohne Probleme minimiert startet ist der IE.
Gruß, Nobby
Hallöchen, Sören,
besten Dank :klasse:
Gruß, Nobby
Hallöchen,
ich habe ein neues Nightly-Profil angelegt, es steht auf "Updates automatisch installieren". Starte ich den Browser und ein Update ist vorhanden, installiert sich das soweit kommentarlos, kurz wird auch ein Fortschrittsbalken angezeigt. Mit dem alten Profil kam vor der Update-Installation immen noch das Fenster der Windows 7-Benutzerkontensteuerung dazwischen, welches ich erst bestätigen musste, dann begann die Update-Installation. Was ist nun normal?
Gruß, Nobby
Habe wieder Darstellungsprobleme bei https://spiele.rtl.de/spiele/rtl-spiele/wwm
Wie bekomme ich die Seite auch mit uBlock angezeigt?
Du mußt
rtl.de
google.com
imasdk.googleapis.com
grün erlauben. Falls google.com nicht zu sehen ist, die ganzen Skripte (Inline etc.) mal freigeben und hinterher wieder auf grau schalten. Dann sollte das Millionärsspiel laufen.
Gruß, Nobby
Bestens, lieber Sören - ich möchte mich auch ganz herzlich für Deine Erklärung und Dein großes Engagement hier bedanken :klasse:
Gruß, Nobby
Richtig, das ist erst für Firefox 64 geplant.
Ich schätze mal, dass der Grafiktreiber für das Rendern an sich zuständig ist. Wenn ich den Schalter aktiviere, scrollen die Webseiten deutlich gebremster. Da mein Laptop schon betagter ist, bekomme ich von Intel kein Update mehr.
Gruß, Nobby
Danke für die Erklärung, Sören. So hab ich es in etwa kapiert, was damit gemeint ist. Spasshalber schaute ich mal in die Firefox-Versionen 62 Release und Beta. Dort ist dieser Schalter defaultmäßig deaktiviert.
Gruß, Nobby
... was besagt denn der umgelegte Schalter?
Ich konnte dazu nur folgendes finden, habe aber davon nicht den blassesten Schimmer, wenn's soweit ins Getriebe rein geht:
https://hg.mozilla.org/mozilla-central/rev/716d49302a28
Nur, dass das Aktivieren wohl irgendwie Performance warum auch immer kostet :wink:
Hallöchen,
der Bug scheint in mit einem Update von heute gefixed worden zu sein, die Felder sind beim Aufruf der Einstellungn hier nicht mehr ausgegraut, alles wieder in Ordnung. Ich markiere somit den Thread mal als gelöst.
Gruß, Nobby
macht es einen unterschied wenn du die einstellung layout.display-list.retain.chrome in about:config auf false setzt und einmal neu startest?
Super, besten Dank - und ob das einen Unterschied macht. So rennt der Fuchs wieder wie gewohnt :klasse:
Gruß, Nobby
Ich habe nun eine viel genauere Auswahl, die erste 64.0a vom 04.09. 23:52 Uhr war noch in Ordnung:
app_name: firefox
build_date: 2018-09-04
build_file: C:\Users\Admin\.mozilla\mozregression\persist\2018-09-04--mozilla-central--firefox-64.0a1.en-US.win32.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/ni…en-US.win32.zip
changeset: bade35bc346f3bc1f5e8b59d3d49c7a1ba28166c
pushlog_url: https://hg.mozilla.org/mozilla-centra…064bbdc130a0040
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central
Dann kam am selben Tag um 23.59 Uhr die erste schlechte Version:
app_name: firefox
build_date: 2018-09-04 23:59:31.358000
build_file: C:\Users\Admin\.mozilla\mozregression\persist\c3734e0f634e--mozilla-central--target.zip
build_type: inbound
build_url: https://queue.taskcluster.net/v1/task/JKcEPm…ld%2Ftarget.zip
changeset: c3734e0f634e10ad994112e49d1849817c1688ff
pushlog_url: https://hg.mozilla.org/mozilla-centra…d1849817c1688ff
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central
task_id: JKcEPm9vSIOQgsko-P7K9g
Vielleicht ist das hilfreicher.
Gruß, Nobby
nachdem das tool mit den nightly versionen durch ist, sollte es auf mozilla-inbound/autoland builds wechseln, wo die einzelnen patches die in nightly aufgenommen werden landen. am ende steht dann in der regel eine einzige änderung/ein einzelner bug, der das problem ausgelöst hat & mit dieser information findet man häufig schnell einen verantwortlichen, der das problem auch wieder gerade biegen kann...
Der Fehler liegt zwischen diesen beiden Versionen - die letzte gute:
app_name: firefox
build_date: 2018-09-03
build_file: C:\Users\Admin\.mozilla\mozregression\persist\2018-09-03--mozilla-central--firefox-63.0a1.en-US.win32.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/ni…en-US.win32.zip
changeset: d14aaf65a80b3baddb193fa6707e4515e4a44609
pushlog_url: https://hg.mozilla.org/mozilla-centra…d49c7a1ba28166c
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central
Die erste schlechte:
app_name: firefox
build_date: 2018-09-04
build_file: C:\Users\Admin\.mozilla\mozregression\persist\2018-09-04--mozilla-central--firefox-64.0a1.en-US.win32.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/ni…en-US.win32.zip
changeset: bade35bc346f3bc1f5e8b59d3d49c7a1ba28166c
pushlog_url: https://hg.mozilla.org/mozilla-centra…d49c7a1ba28166c
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central
Gruß, Nobby
Hallöchen madperson,
mozregression habe ich im Einsatz. Damit habe ich herausgefunden, dass seit der ersten Version der Nightly 64.0a1 (32-bit) dieses Scrollproblem bei mir auftaucht. Die letzte 63er-Nightly war in dieser Richtung noch okay. Das Tool ist super, um Fehler zu finden.
Gruß, Nobby
Hallöchen,
mir ist zufällig aufgefallen, dass die Scroll-Performance der neuen Nightly 64.0a1 vom 05.09. (32-bit) schlechter ist als bei der 63er-Nightly im direkten Vergleich. Das Scrollen gerade durch längere Seiten ist nicht mehr schön schnell und direkt mit dem Mausrad, es wirkt leicht verzögert, etwas hinterherhinkend, nicht mehr "Quantum like" :wink: Okay, das ist die erste 64er-Alpha, aber hat sich da etwas gravierendes in dieser Richtung "unter der Haube" geändert? Auch die aktuelle 62er Release und Beta scrollen wie gewohnt schön fix.
Getestet im abgesicherten Modus und auch mit frischem Profil, bleibt gleich. Mein Rechner ist weißgott nicht mehr der Jüngste, ich bekomme auch keine aktuellen Grafiktreiber mehr. Aber wie oben erwähnt, die älteren Füchse rennen sehr gut. Ich weiß natürlich nicht, ob das mit aktueller Hardware überhaupt auffällt.
Gruß, Nobby
In einem neuen Profil ist das Verhalten doch klar, gibt es doch da noch keine Daten die du löschen oder verwalten kannst.
Ist zwar irgendwie unlogisch, aber selbst mit einen ganz frischen Profil sind diese Schaltflächen normalerweise nicht ausgegraut. Habe das gerade mal mit der letzten, funktionierenden Build getestet.
Gruß, Nobby
Also ausprobiert sowohl im Safe Mode als auch mit einem vollkommen neuen Profil. Ob das speziell an der 32-Bit-Version liegt :-?? Ich habe hier noch Windows 7 am Start.
Gruß, Nobby
Hallöchen,
alles getestet mit der "blanken Version" 63.0a1-2018-09-03 (32 bit), da hat sich in der Einstellungsseite (Preferences) ein Fehler eingeschlichen. Wenn ich diese aufrufe und auf "Datenschutz & Sicherheit" gehe, sind die Schaltflächen "Daten entfernen" und "Daten verwalten" ausgegraut. Erst wenn ich die Seite aktualisiere, dann kann ich die Felder ancklicken: Letzte Version, die noch funktionierte, mit mozregression verglichen:
app_name: firefox
build_date: 2018-09-03 15:49:50.405000
build_file: C:\Users\Admin\.mozilla\mozregression\persist\75411571f3a4--mozilla-inbound--target.zip
build_type: inbound
build_url: https://queue.taskcluster.net/v1/task/AUb9dl…ld%2Ftarget.zip
changeset: 75411571f3a4aeabbc1697b5dd7f4f827af3d29d
pushlog_url: https://hg.mozilla.org/integration/mo…694745b9d175c24
repo_name: mozilla-inbound
repo_url: https://hg.mozilla.org/integration/mozilla-inbound
task_id: AUb9dlJ4TROa_BJK_Gmx2Q
Kann das jemand nachvollziehen? Heute kam die 64.0a1 raus, die den Fehler mitgenommen hat.
Gruß, Nobby
Hallöchen Sören,
aber die userChrome.css und auch die userContent.css funktionieren weiterhin wie gewohnt? Die fand ich bisher eine feine Sache zur Anpassung der Oberfäche und zum vornehmen individueller Anpassungen auf speziellen Webseiten.
Gruß, Nobby
Hallöchen,
mir fiel das bei ebay auf, nachdem ich in meinen privaten Bereich wechseln wollte, kam der Sicherheitshinweis. Also abwarten, bis die Webseitenbetreiber ihre Symantec-Zertifikate aktualisiert haben, wenn ich das richtig verstanden habe.
Gruß, Nobby
