Der Artikel ergründet die spezifische Ursache für "vergessene" CSS-Angaben und scheinbar geblockte Javascripts im Firefox hinsichtlich der Postbacks einer ASP.NET-Anwendung.
UPDATE: Die Ursache liegt letztendlich nicht am Browser (der Effekt ließ sich im IE mit ebenfalls falschem User-Agent reproduzieren), sondern am IIS Webserver. Mehr Infos hier
Seit gestern beschäftigte mich folgendes Problem: mein Firefox führte einige Javascripts nicht mehr aus und auch in puncto CSS ignorierte er manch simple Angabe, wie z.B die Breite einer Textbox. Erst dachte ich, meine Homepage wäre fehlerhaft, dann stellte ich fest, dass es auf anderen Webseiten auch auftritt.
Seltsam war vor allem, dass nur manche Javascripts nicht ausgeführt wurden. Ein Blick in den Quellcode offenbarte schnell, dass die Javascript-Funktionen teilweise komplett fehlten und auch "Not found"-Fehler in der JS-Konsole erzeugten. Wie es schien, funktionierten in erster Linie meine selbst geschriebenen Scripte - die vom IIS generierten "Hilfsscripte" zum besseren Funktionieren der ASP .NET Anwendung jedoch nicht. Steuerelemente die einen durch Javascript initiierten Postback auslösen waren funktionslos. Die entsprechenden Funktionen waren im Quellcode einfach nicht vorhanden. Die selbe Seite mit dem IE geöffnet: der Quellcode war sofort um einige Zeilen länger und alles funktionierte. Auch auf anderen Rechnern funktionierte es mittels Firefox, ja sogar der "Firefox Portable" [1] funktionierte auf dem selben Rechner. Am Webserver bzw. an der Webseite konnte es somit also nicht liegen.
Na wo klemmt's denn?
Die nächste Vermutung war daher, dass irgend etwas diese Scripts blockieren muss. Ich habe zwar das Addon "NoScript" [2] installiert, doch für die jeweilige Seite war es deaktiviert. Selbst das komplette Deaktivieren der Erweiterung machte keinen Unterschied. Anschließend deaktivierte ich sogar alle installierten Erweiterungen - ohne Erfolg. Nach wie vor liefen einige Javascripts nicht und nach wie vor ignorierte Firefox manche CSS-Anweisungen.
Als letzte Maßnahme deaktivierte ich die Firewall, das Antiviren-Programm und den Spamfilter. Aber auch das brachte keine Änderung.
Nach dem Löschen ist vor dem Löschen
Als letzten Ausweg sah ich die Neuinstallation von Firefox. Dabei musste ich feststellen, dass nach einer Deinstallation noch alle Einstellungen erhalten bleiben. Komischerweise kam nicht einmal eine Nachfrage, ob ich das möchte. Folglich war nach der anschließenden Neuinstallation wieder alles beim Alten *g* Also wieder deinstalliert und diesmal auch nach den üblichen Verdächtigen geschaut: im Installationsverzeichnis waren noch ein paar Dateien übrig und in den persönlichen Anwendungsdaten befand sich noch der komplette Profilordner (Standard: default) mit sämtlichen Einstellungen, Erweiterung und Bookmarks. Erst nach dem Löschen dieses Ordners, war Firefox wieder clean. Scheinbar würde es auch vollkommen ausreichen einfach diesen Ordner zu löschen, da sämtliche Einstellungen da drin gespeichert werden. Die Deinstallation hätte ich mir sicher sparen können.
Der erste Test im "cleanen" Firefox zeigte, dass nun wieder alles wie gewünscht funktionierte. Mittels MozBackup [3] spielte ich alle meine Einstellungen wieder zurück. Wie sich herausstellte, die Fehlfunktion ebenfalls. Das war der Punkt, an dem ich beschloss doch nochmal genauer nachzuforschen. Ich löschte also wieder den Profil-Ordner und spielte diesmal nur die Einstellungen zurück, keine Erweiterungen oder Bookmarks noch sonst irgendwas. Die Ursachen grenzten sich so langsam ein und wurden nun überschaubar, denn diesmal trat das Problem erneut auf. Es musste jetzt also an einer Firefox-internen Einstellung liegen.
Nun begann ich in bester Trial-And-Error-Manier sämtliche Einstellungen unter about:config Stück für Stück auf die Standardwerte zurückzusetzen. Bis ich dann schließlich die Ursache gefunden hatte. Der Schlüssel
general.useragent.override
war mit dem Wert "Mozilla/5.0" belegt. In der Standardkonfiguration ist dieser Wert leer. Nach dem Zurücksetzen dieses Wertes, funktionierte wieder alles einwandfrei 
Seltsamerweise ist es völlig egal womit der Schlüssel belegt ist. Das Problem tritt stets dann auf, wenn der Wert "vom Benutzer festgelegt" wurde, insofern man keinen korrekten User-Agent-String angibt.
K(l)eine Ursache, große Wirkung
Wäre der Wert auf etwas wie "Mozilla/1.0" belegt gewesen, hätte man ja noch mutmaßen können, dass der Webserver "denkt", dass der Client zu alt ist, das Javascript sowieso nicht kapiert und es daher gar nicht erst ausliefert. Oder dass der Webserver durch den User-Agent einfach "verwirrt" ist und/oder es ein Bug im IIS ist. Doch all das scheint nicht die Ursache für das Problem zu sein. Ich vermute eher, dass mein Firefox spinnt, was angesichts der Tatsache, dass ich Mozbackup schon seit längerem benutze gar nicht so abwegig ist. Als ich nämlich etwas in der about:config stöberte, stolperte ich über etliche Einträge von Extensions, die ich schon seit Ewigkeiten nicht mehr installiert habe. Ich denke, dass meine Config daher komplett zugemüllt ist. MozBackup kopiert scheinbar immer alle Einstellungen komplett und stellt anschließend auch alles wieder komplett her. Somit sammelt sich mit der Zeit natürlich etliches an unnötigem Balast an.
Sendet der Browser einen nicht korrekten User-Agent-String, dann kann der Webserver (IIS) nicht erkennen, ob der anfragende Browser Javascript verarbeiten kann. Aus diesem Grund macht dieser sich gar nicht erst die Mühe und generiert die für Postbacks teilweise notwendigen Scripte nicht. Dadurch bleiben die meisten Steuerelemente einer ASP .NET Anwendung ohne Funktion. Mehr Details hier.
[1] Firefox Portable
[2] NoScript
[3] MozBackup