Nur nochmal so am Rande - der "multiplefirefoxloader" ist veraltet und wurde durch das aktuelle "FirefoxLoader.exe" ersetzt. "multiplefirefoxloader" fragt sinnfrei die Registry nach einem installierten Firefox ab, den Code habe ich grad nicht vorliegen, aber wenn man den portable Firefox laden will, ist der Nachfolger die richtige Wahl. Das Ergebnis ist das gleich, nur ohne Umwege. Weg vom alten Geraffel, ob es nun noch funktioniert oder nicht, was aufgrund eines fehlenden Protokolls nicht ermittelt werden kann. Ich hatte das neulich schon so (ähnlich) beschrieben mit Link zu stadt-bremerhaven, wo das so zu lesen war.
Eine Anmerkung zu #270 mit der Verwendung des Starters.
Der Starter gibt jeglichen Parameter an Firefox weiter, der dort unter \Firefox angelegt ist. Wenn man allerdings ein Profil aus der profiles.ini nutzen will, reicht der Verweis auf <laufwerk>:\<pfad>\firefox.exe, da ist der Starter komplett überflüssig und das ist auch mit einem regulären (empfohlen!) machbar. Eine Portable stellt in dem Sinne eine bedrohte Version dar, die ist nicht vom System geschützt ist, auch das Profil nicht. Man kann allerdings via profiles. ini einen jeglichen Profilpfad nutzen (geschützt oder nicht).
Was der portable Starter nicht beachtet, warum die Nutzung von Scripten fehlschlagen kann - der Starter setzt nicht das Arbeitsverzeichnis zu Firefox.exe, es gibt Programme, die das zwingend benötigen, weil sie es als Root für alle (relativen) Zugriffe benötigen. Ohne es getestet zu haben, könnte Firefox so ein Programm sein. Wenn das Arbeitsverzeichnis auf dem Starter-Verzeichnis sitzt, müssen Zugriffe auf Scripte fehlschlagen, weil das ein anderes Verzeichnis ist, als wo firefox.exe liegt und dort keine Scripte existieren. Es hat also mindestens einen triftigen Grund, warum eine Portable als dauerhaft genutzte Version zu meiden ist. Leider wissen das zu wenige.