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..

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.

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.

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.

Zitat von Drachen

Zitat von tobias.x

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...

Zitat von .DeJaVu

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...

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..

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?