Dropdownboxen funktionieren seit 68.0.x nicht mehr - Ursache war: user_pref("browser.tabs.remote.desktopbehavior", false);

  • Seit der Version 68.0.x ESR funktionieren bei allen von mir betreuten PCs die Dropdownboxen nicht mehr.

    Mit 60.8.x ESR funktioniert alles perfekt, ebenso natürlich mit den Vorgängerversionen.

    Der Effekt:

    Man klickt auf den Pfeil neben der Dropdownbox, aber sie klappt nicht auf.

    Behelfsweise kann man folgenden Workaround benutzen:

    - auf den Pfeil klicken

    - ins Textfeld der Dropdownbox klicken

    - nun mit den Cursortasten (auf und ab) den passenden Eintrag suchen und stehen lassen.

    Das ist natürlich wenig intuitiv.

    Betroffene Webseiten:

    - Fritzbox, Switch-GUIs, Router+Firewalls, aber eben auch normale Webseiten.

    Betroffene Systeme:

    - Windows 7 und Windows 8.1, ebenso unter Server 2008R2 - stets auf dem neuesten Stand mit allen auch optionalen Updates außer Silverlight und monthly previews.

    - AMD und Intel PCs, Alter 1 - 12 Jahre, RAM 4-16 GByte.

    - Mit und ohne Virenscanner (Avira pro (nur die Dateiwächter-Komponente aktiv) bzw. Windows Defender)).

    - Installierte Addons: Keines oder maximal uBlock Origin.

    - Profilverzeichnis auf Server im Homedir des Benutzers (Cache usw. aber lokal auf C: (per user.pref verlegt) )

    - Installationsverzeichnis: Standard (C:\Program Files (X86)\

    Getestet aufgrund ähnlicher Foren Meldungen:

    - Abgesicherter Start von Firefox ohne Addons

    - Abschalten der Hardwarebeschleunigung.

    Beides ohne Erfolg.

    Da das Problem zwar bei mir zu 100% auftritt, bei anderen Nutzern aber so gut wie gar nicht, wäre ich nun an einer Idee zur Fehlersuche bzw. Eingrenzung interessiert...

    Vielen Dank schon einmal..

    2 Mal editiert, zuletzt von tobias.x (19. August 2019 um 17:22)

  • Lass doch mal das about:support von einem Rechner sehen, wo Avira drauf ist

    Und - abgesicherter Modus schaltet keine user.pref etc ab, die wirken dennoch. Es hilft nur, ein neues Profil zu testen und davon dann bitte auch das about:support.

    Wenn du weinen möchtest, bist du falsch hier. Hier gibt es nur Lösungen!
    Oh Herr, wirf Hirn, oder Steine - Hauptsache, du triffst endlich.
    Zu viele Goofies und Dulleks vom Dienst. Schlabokka!

  • Danke für die schnelle Antwort.

    Auf die Rechner mit Avira habe ich so schnell jetzt keinen Zugriff.

    Aber ich würde gerne mal die Einstellungsdatei hochladen, die bei meinen Benutzern bei jeder Anmeldung zwangshochgeladen wird. Vielleicht hast Du mich hiermit ja auf eine heiße Spur gebracht. Wobei das eigentlich auch nur bei ca. zweidrittel der Rechner passiert...

    (Die Endung .js hat die Forensoftware nicht akzeptiert, deshalb noch das .txt am Ende).

    user.js.txt

  • Per RDP habe ich mich nun einmal auf einen anderen PC aus einer anderen Domäne eingeloggt. Hier dürfte die user.js etwas anders sein als oben. Die Dropdownboxen klappen aber auch hier seit der 68.0.x nicht mehr auf.

    Die about:support - Daten (Das kannte ich bisher noch gar nicht - sehr interessant!) habe ich der Übersichtlichkeit halber mal in eine Word-Datei alten Formats kopiert, ein .txt angehängt (doc und rar werden von der Forensoftware geblockt..) FF Dropdownbox-Probs about-support.doc.txt und hier hochgeladen. Bitte das .txt vor dem Öffnen wieder entfernen.

    Vielleicht sieht ja jemand hier schon einen Grund, warum Dropdownboxen nicht aufklappen könnten?

    Als nächstes werde ich das dann am selben PC mal mit neuem Profil probieren und berichten.

  • falsch(.tabs. nicht .tab. laut Webseite):

    https://support.mozilla.org/de/kb/firefox-…rgrund-zu-laden

    Code
    user_pref("browser.tab.remote.autostart", false);
    user_pref("browser.tab.remote.autostart.2", false);

    richtig

    Code
    user_pref("browser.tabs.remote.autostart", false);
    user_pref("browser.tabs.remote.autostart.2", false);

    davon veraltet

    Code
    user_pref("browser.tabs.remote.autostart.2", false);

    https://support.mozilla.org/de/questions/1207724

    Warum wurde der Cache in einen unsicheren Bereich verlegt?

    C:\\temp\\ff

    Das ist ausserhalb vom Benutzerordner und damit kritisch.

    Zitat

    Man klickt auf den Pfeil neben der Dropdownbox, aber sie klappt nicht auf.

    Das betrifft jetzt die Firefox Einstellungen oder Webseiten?

    Mit der (bereinigten) user.js von dir kann ich in den Einstellungen nichts feststellen. Deswegen ist das about:support wichtig.

    Wenn du weinen möchtest, bist du falsch hier. Hier gibt es nur Lösungen!
    Oh Herr, wirf Hirn, oder Steine - Hauptsache, du triffst endlich.
    Zu viele Goofies und Dulleks vom Dienst. Schlabokka!

  • Danke für die Durchsicht.. die fehlerhaften Einträge werde ich natürlich korrigieren.

    Um auf Deine Fragen zu antworten:

    Den Temp Ordner habe ich schon vor fast 20 Jahren nach C:\temp verlegt, weil einfach ein Cache auf einem Netzlaufwerk in meinen Augen nicht sehr produktiv sein kann.. Damals noch viel weniger als heute. Das Profil muss aber dennoch auf dem Netzlaufwerk sein, weil Lesezeichen usw. für den jeweiligen Benutzer ja an jedem PC funktionieren sollen, und nicht nur an einem bestimmten.

    Heute könnte man das Temp-Verzeichnis für den Firefox natürlich auch ins lokale Appdata verlegen - aber das lohnt den Aufwand nicht. Außerdem bin ich mir nicht sicher, ob der FF Variablen wie %username% in den Pfadangaben auflösen kann? Das Temp-Verzeichnis wird sowieso spätestens bei jedem Einloggen in Windows (vom Windows-Login-Script) gelöscht...

    Und ja, es wäre natürlich einfach, die Roaming Profiles von Windows zu nutzen, die es nun ja schon seit längerem gibt. Aber erstens habe ich auch diverse Umgebungen mit Linux-Servern im Einsatz (ja ich weiß, auch Samba kann das mittlerweile), und zweitens ist das mit den Roaming Profiles von Windows sehr zähl und fehleranfällig. Das will ich also nicht. Deshalb also die manuelle Konfiguration im FF.

    Nebenbei bemerkt: Mittlerweile gibt es im Firefox noch weitere Caches, die dann größtenteils sowieso im Profil auf dem Netzlaufwerk liegen und von meinen Anweisungen gar nicht beeinflusst werden.. :(

    Was die Frage nach den Dropdownboxen betrifft:

    Ja, es geht nur um native Dropdownboxen in HTML auf Webseiten und Geräte-GUIs. Es geht nicht z.B. um solche grafischen Menüs, wie sie z.B. in Wordpress gerne erzeugt werden über irgendwelche Layer-Boxen etc., also vermutlich mit viel Javascript.

    5 Mal editiert, zuletzt von tobias.x (20. August 2019 um 17:16)

  • Update:

    Am selben PC, von dem ich die about:support gepostet habe, funktionieren die Dropdownboxen korrekt, wenn ich den Firefox mit einem ganz frischen Profil (ebenfalls auf dem Server liegend) aufrufe.

    Insofern weiß ich nun, dass ich notfalls Schritt für Schritt immer mehr Dateien aus dem Profil löschen kann, um herauszufinden, wo der Bösewicht sitzt...

    Aber vielleicht hat ja trotzdem noch jemand eine Idee... :)

    Ansonsten werde ich aber meine Ergebnisse hier natürlich auch gerne kund tun.

    Das Tückische war ursprünglich gewesen, dass ich wegen der flächendeckenden Problematik bei mir gar nicht davon ausging, dass der Fehler bei mir liegen könnte .. .) Das weiß ich nun ja glücklicherweise besser...

    Auf Wunsch poste ich natürlich auch gerne noch die about:support mit dem funktionierenden Profil. Dann bitte noch mal kurz Bescheid sagen. Danke.

    Einmal editiert, zuletzt von tobias.x (20. August 2019 um 17:12)

  • Vergleich doch für den Anfang einfach die prefs.js.Und da nur Abweichungen zwischen true/false. Oder benenne es in prefs_js.bak um und lasse Firefox eine neue anlegen und vergleiche später beide.

    Was zu

    Zitat

    weil einfach ein Cache auf einem Netzlaufwerk in meinen Augen nicht sehr produktiv sein kann.

    Aber das Profil schon, oder?

    Zitat

    Profilverzeichnis auf Server im Homedir des Benutzers

    Ich hab zwar keinen Server zur Hand, aber das Profil liegt unter %appdata% und der Cache unter %localappdata%.

    Wenn du schon den Cache umlegst, dann wäre doch %temp% bzw %localappdata%\Temp\ sinnvoller, oder nicht?

    Ich kann hier über das Netzwerk hinweg auch Profile nutzen, das ist aber kein Vergleich zu einer Domäne/Server. Läuft aber stabil und fehlerfrei.

    Zitat

    Mittlerweile gibt es im Firefox noch weitere Caches

    Kein Cache im eigentlichen Sinne. Was meinst du konkret?

    Was spricht eigentlich dagegen, Firefox im Ganzen auf dem Server zu lassen und per Remote-Session nutzbar zu machen? Warum hat MS den zuletzt das gesamte Hyper-V Geraffel aufpoliert ? :D

    Wenn du weinen möchtest, bist du falsch hier. Hier gibt es nur Lösungen!
    Oh Herr, wirf Hirn, oder Steine - Hauptsache, du triffst endlich.
    Zu viele Goofies und Dulleks vom Dienst. Schlabokka!

  • Und ja, es wäre natürlich einfach, die Roaming Profiles von Windows zu nutzen, die es nun ja schon seit längerem gibt.

    Die gibt es sogar schon einiges länger als die "fast 20 Jahre", die du deine Cache-Ordner schon auf C:\Temp\ legst ;)

    MfG

    Drachen

    Na, aber nicht unter Samba. Und dann ist ja die Sache die, dass man dafür auch einheitliche Windows-Versionen auf den Clients haben sollte, und sinnvollerweise auch auf allen Clients dieselben Programme, damit dann (nur mal als harmloseres Beispiel), die Desktopverknüpfungen zu Programmen auch überall funktionieren. Und das Ganze war damals ZÄH.. beim Ein- und beim Ausloggen, und zudem fehleranfällig.

    Das nur wegen der FF-Profile einzurichten wäre IMHO Quatsch und würde die Benutzer nur unnötig nerven. Bisher hat das jetzige Verfahren ja auch bestens und auch flott funktioniert...

  • Ich hab zwar keinen Server zur Hand, aber das Profil liegt unter %appdata% und der Cache unter %localappdata%.

    Wenn du schon den Cache umlegst, dann wäre doch %temp% bzw %localappdata%\Temp\ sinnvoller, oder nicht?

    Das wäre eine Überlegung wert ... aber kann Firefox das denn überhaupt umsetzen, wenn ich dort in der entsprechenden user.js ein %localappdata% als Pfad eintrage?

    Wobei %temp% ohnehin wieder in C:\temp landen würde, denn das habe ich auf den Windows-Clients so eingestellt, um es bei Logins regelmäßig "putzen" zu können :)

  • Zitat
    Zitat

    weil einfach ein Cache auf einem Netzlaufwerk in meinen Augen nicht sehr produktiv sein kann.

    Aber das Profil schon, oder?

    Naja, wenn da nur ein paar Initialisierungen und Addons ausgelesen werden, klar. Natürlich ist das Profil vom Firefox immer schreibintensiver geworden im Laufe der Zeit mit all den Listen und Datenbanken, die dort mittlerweile liegen. Trotzdem ist ein Cache nach meinem Verständnis wesentlich besser auf einem lokalen Laufwerk aufgehoben.

    Und das Profil auf dem Server ist halt für die Funktionsweise zwingend notwendig.

    Oder ich müsste es bei jedem Einloggen auf den Client-PC kopieren und nach dem Ausloggen wieder zurück.

    Aber das war bisher nicht nötig.


    Zitat
    Zitat

    Mittlerweile gibt es im Firefox noch weitere Caches

    Kein Cache im eigentlichen Sinne. Was meinst du konkret?

    Na zum Beispiel:

    die Ordner "startup-Cache", "jump-ListCache"... die tragen das Wort ja sogar im Namen..

    Zitat

    Was spricht eigentlich dagegen, Firefox im Ganzen auf dem Server zu lassen und per Remote-Session nutzbar zu machen? Warum hat MS den zuletzt das gesamte Hyper-V Geraffel aufpoliert ?

    Dagegen spricht, dass kein Terminalserver zur Verfügung steht... :) Ebensowenig die Lizenzen. Und auch, dass es Overkill wäre, jedenfalls in meinen Augen. Zumal der Firefox nicht gerade das Haupt-Arbeitsmittel an den Arbeitsplätzen ist, sondern eher selten genutzt wird.

  • Lösung des Dropdownlisten Problems:

    Ich hatte mir nun vorgenommen, an einem PC nach und nach Ordner und Dateien eines Benutzerprofils durch Umbenennen zu deaktivieren und anschließend wieder zu aktivieren und mit dem nächsten Element fortzufahren.

    Gleich mein erster Versuch war ein Volltreffer:

    Die prefs.js

    Sobald ich diese lösche und der FF sie aus der user.js usw. neu erstellt hat, klappen die Dropdown-Menüs wieder auf.

    Notfalls werde ich also nur diese Datei löschen.

    Trotzdem war ich natürlich neugierig, welche Einträge innerhalb dieser Datei nun die Ursache sind.

    Zunächst fiel auf, dass in der Datei praktisch sämtliche Drucker und Addons, die jemals in dem Firefox auf dem PC installiert waren, ihre Spuren hinterlassen haben, und zwar nicht zu knapp.... So ist die historisch gewachsene prefs.js 60 kByte groß, während die vom FF neu erstellte nur 8 kByte groß ist..

    Vermutlich ist die Ursache also irgendein Eintrag, den irgendeines der Addons, die ich so gut fand, dass ich sie irgendwann einmal praktisch überall installiert hatte, dort hinterlassen hatte - obwohl es gar nicht mehr installiert ist..

    Den "Schuldigen" habe ich aber leider immer noch nicht gefunden, obwohl ich mir einbilde, die Einträge aller Addons, die ich gerne mal benutzt hatte, gelöscht zu haben.

    Überhaupt habe ich bei dieser Aktion Lust bekommen, mal die kompletten Profile zu entrümpeln. Was hier an ur-ur-uralten Dateien herumliegt, ist nicht mehr feierlich...

  • Addons dürfen das IMO nicht mehr, daher tippe ich auf eine Hinterlassenschaft aus der Zeit vor Firefox 57. Dann wird es eh höggschte Eisenbahn, das Profil neu anzulegen.

    Was den "Cache" angeht, ja, ich würde es aber eher als "preload" einstufen

    https://wiki.mozilla.org/StartupCache

    jumpListCache

    jumpListCache automatisch löschen

    Ist also schon sehr alt.

    Sollte man beides so lassen. Man könnte Firefox das auch alles weglöschen, nur dann leidet eben die Performance. Chromium ist da nicht anders, sogar exzessiver.

    Bei Erweiterungen ist ublock Spitzenreiter hier, >35md Storage von 185mb (chromium ähnlich) Storage+Extensions machen hier 85mb aus. Deswegen sollte man Firefox nicht reglementieren und bereinigen wollen, Peanuts.

    Was Variablen angeht, ich gaube nicht, dass Firefox die versteht... Nein, er legt sofort \cache2\ im Profil an. Muss also fix sein.

    Wenn du weinen möchtest, bist du falsch hier. Hier gibt es nur Lösungen!
    Oh Herr, wirf Hirn, oder Steine - Hauptsache, du triffst endlich.
    Zu viele Goofies und Dulleks vom Dienst. Schlabokka!

  • Ich habe nun die Ursache des Problems gefunden:

    Nachdem nach Löschen der prefs.js das Problem scheinbar gelöst war, trat es nach dem nächsten Login gleich wieder auf.

    Somit war nun klar, dass die Ursache in der user.js liegen muss, die bei jedem Windows-Login in das FF-Profil des Benutzers kopiert wird.

    Nach einiger weiterer Suche habe ich nun die Einstellung, welche das Aufklappen der Dropboxen verhindert, in der user.js (und somit später dann auch in der prefs.js) gefunden:

    Sobald ich folgende Zeile auskommentiere (und anschließend die prefs.js lösche), funktionieren die Dropdownboxen wieder:

    user_pref("browser.tabs.remote.desktopbehavior", false);

    Das Problem ist nun also glücklicherweise gelöst..

  • tobias.x 22. August 2019 um 23:41

    Hat den Titel des Themas von „Dropdownboxen funktionieren seit 68.0.x nicht mehr - alle ca. 60 unterschiedlichsten PCs betroffen“ zu „Dropdownboxen funktionieren seit 68.0.x nicht mehr - Ursache war: user_pref("browser.tabs.remote.desktopbehavior", false);“ geändert.
  • Die Frage die sich mir stellt - warum wurde überhaupt an multi-process geschraubt, wo doch die Auswirkungen zu dem Zeitpunkt überhaupt nicht klar waren? Es ist nicht so, dass ich nicht ausprobiere und auch mal was daneben gegangen ist - aber bei euch ist das ein Produktivsystem, da sollte man Firefox in den Grundfunktionen eigentlich genau so lassen. Ist übrigens ein Relikt aus der Zeit vor Quantum - und das hatte ich oben ja schon angesprochen, solche Profile habe immer eine Macke weg und sollten neu erstellt werden. Allerdings hatte ich keine Probleme mit der user.js von dir, ich hatte später auch gefragt, WO das auftritt, eben deswegen.

    Der Eintrag ist mir übrigens leider durchgegangen, nach erneuter Durchsicht würde ich auch empfehlen, alles von browser.tabs.remote rauszunehmen, weil kontraproduktiv. Ebenso alls zu plugin, weil das eh nicht mehr unterstützt wird - weder WMP, pdf, QT, allenfalls noch Flash bis Anfang 2020 und Silverlight. Pocket wird in dem Moment deaktiviert, sobald es nicht mehr auf der Benutzeroberfläche ist, fällt IMO eh schon unter Zusatzleistungen. Der eintrag dazu

    user_pref("extensions.pocket.enabled", 0);

    ist auch falsch, das ist Typ boolean und daher nur true/false

    user_pref("plugin.state.nppdf", 0);

    plugin.state gibt es hier nur noch für Flash (siehe oben)

    Nicht sicher, ob es das noch gibt, evtl Sören fragen

    user_pref("pref.privacy.disable_button.clear_cache", false);

    https://support.mozilla.org/de/kb/firefox-…config-anpassen

    Wenn du weinen möchtest, bist du falsch hier. Hier gibt es nur Lösungen!
    Oh Herr, wirf Hirn, oder Steine - Hauptsache, du triffst endlich.
    Zu viele Goofies und Dulleks vom Dienst. Schlabokka!

  • Also auf Deine Frage nach dem warum:

    Ich kann mich ehrlich gar nicht mehr erinnern, aber wenn Du etwas von Multiprozess schreibst, dann kommt eine schwache Erinnerung hoch, dass Firefox nach irgendeinem Update an vielen PCs praktisch unbenutzbar geworden war. Dann ich suchte ich halt im Internet - und offenbar waren es diese tab.remote. Einträge, die sofortige Abhilfe brachten. Klar, man sollte das gelegentlich mal checken... aber solange alles gut läuft... die np-Plugin Einträge habe ich jetzt auch mal rausgenommen, ich denke, dass diese Art von Plugins ja sowieso nicht mehr funktioniert und zumindest Quicktime und Mediaplayer Addons, die einem nervigerweise immer untergejubelt wurden, wind ja nun auch glücklicherweise Schnee von gestern .-). Wenn ich mir die prefs.js anschaue, das ist noch viel lustiger.. all die Einträge, die sich dort seit teilweise über 10 Jahren angesammelt haben .. :) Vielleicht werde ich beim Umstieg auf 64 Bit mal einen Schnitt mit der prefs.js machen bzw. mit den gesamten Benutzerprofilen..

    BTW: Ich habe nun die browser.tabs.remote-Einträge für die ersten Benutzer manuell aus der prefs.js entfernt, was aber doch etwas mühselig ist. Ich will aber nicht zuviele individuelle Einstellungen, die es möglicherweise gibt, löschen, und deswegen auch die prefs.js nicht einfach löschen.

    Gibt es eigentlich auch eine Methode, (eine Art Befehl), wie ich über die user.js einen Eintrag in der prefs.js vom Firefox löschen lassen kann? Ähnlich wie beim Registry-Editor für Windows mit den .reg Dateien?

  • Zitat

    dass Firefox nach irgendeinem Update an vielen PCs praktisch unbenutzbar geworden war

    Dann war das Profil vorher schon geschädigt, kann ich aus meiner Erfahrung nur so sagen.

    Zitat

    Gibt es eigentlich auch eine Methode

    Denke schon, Mozilla kann das ja auch via Hotfix/Studies, behaupte ich. Frag mal Sören ;)

    Wenn du weinen möchtest, bist du falsch hier. Hier gibt es nur Lösungen!
    Oh Herr, wirf Hirn, oder Steine - Hauptsache, du triffst endlich.
    Zu viele Goofies und Dulleks vom Dienst. Schlabokka!

  • Nicht sicher, ob es das noch gibt, evtl Sören fragen

    user_pref("pref.privacy.disable_button.clear_cache", false);

    Nein, gibt es nicht mehr.

    Zitat

    Gibt es eigentlich auch eine Methode, (eine Art Befehl), wie ich über die user.js einen Eintrag in der prefs.js vom Firefox löschen lassen kann?

    Denke schon, Mozilla kann das ja auch via Hotfix/Studies, behaupte ich. Frag mal Sören ;)

    Die Möglichkeit, die Mozilla hat, um aus der Ferne Einstellungen zu verändern, steht regulären Nutzern nicht zur Verfügung, das Gefahrenpotential dahinter wäre riesengroß.

    Letztlich benötigt es dafür keine Lösung innerhalb von Firefox. Man will Dateien bearbeiten, die auf dem Dateisystem liegen. Also verwendet man ein Tool zum Bearbeiten von Dateien, das kann auch das Terminal des Betriebssystems sein. Sofern es die Möglichkeit zum Suchen mit Regex und Ersetzen gibt, ist das lösbar - entsprechende Kenntnisse vorausgesetzt. Sonst bleibt nur der Weg, das von Hand zu machen.

  • Tools für Suchen&Ersetzen gibt es wie sand am Meer und auch kostenlos (nutze selbst S&R von Funduc). Der Aufwand wird sich wohl durch die Suche über die Benutzerprofile hinweg ergeben.

    Das mit der ferngesteuerten Änderung dachte ich mir ja schon, könnt ja dann im Prinzip jede Erweiterung die Sicherheit aushebeln und das ist ja mit Quantum eben bewusst abgewürgt worden.

    Wenn du weinen möchtest, bist du falsch hier. Hier gibt es nur Lösungen!
    Oh Herr, wirf Hirn, oder Steine - Hauptsache, du triffst endlich.
    Zu viele Goofies und Dulleks vom Dienst. Schlabokka!