@Zitronella wegen Portable Starter

Du benötigst Hilfe bezüglich Firefox? Bitte stelle deine Frage im öffentlichen Bereich des Forums und nicht per Konversation an wahllos ausgesuchte Benutzer. Wähle dazu einen passenden Forenbereich, zum Beispiel „Probleme auf Websites“ oder „Erweiterungen und Themes“ und klicke dann rechts oben auf die Schaltfläche „Neues Thema“.
  • Weil ich das anderweitig gelesen habe, dass man evtl die Portable als würg-around Standardbrowser nutzen kann seit dedizierten Profile:
    https://www.winhelponline.com/…efault-programs-in-vista/


    Ich weiss, dass der Starter von Caschy automatisch -no-remote hinzufügt, sobald eine laufende Instanz erkannt wird. Ist das bei dir auch noch so? Dann dürfte der Starter von Caschy und dir in Verbindung mit dem verlinkten Tool nicht zielführend sein.


    War das jetzt zu schnell in Gedanken?


    Also mit nur einem Firefox und einem Standardprofil ist es egal, damit dürften die meisten dieses neue Feature gar nicht bemerken. Die Portable hingegen wird ja mit Parameter für das Profil gestartet und Firefox.exe war bislang ja auch darüber ansprechbar (ohne -no-remote) und hat praktisch diese Anfragen abgefangen. Dass ist ja seit dedizierten Profilen nicht mehr so. Jetzt sind die halt darauf gekommen, den Starter als Standardbrowser einzutragen - macht ja Sinn - und damit wird ja dann praktisch das Profil wieder mit übergeben, was ja den grundsätzlichen Überlegungen entspricht. Was aber eben nicht bedacht wurde, dass der Starter ein -no-remote hinzufügt, sobald eine laufende Instanz erkannt wird. Damit ist das Tool von oben praktisch wertlos, weil der Starter nicht mitspielt.


    Laut gedacht:
    Der Starter müsste eigentlich jetzt eigentlich zusätzlich feststellen, ob seine Firefox-Instanz schon läuft, ob er schon mal aufgerufen wurde. Und das ist nur möglich, wenn es den Pfad zur laufenden Instanz ausliest, es reicht keine INI oder "Flag" dafür, weil der Starter sich ja danach direkt wieder beendet und Firefox arbeiten lässt.



    Abseits davon, folgendes (ähnlich) nutze ich hier, um Firefox festzulegen:
    HKEY_CLASSES_ROOT\Applications\firefox.exe\shell\open\command
    @="X:\Firefox\firefox.exe" "%1"


    Wenn man nicht zwingend die profiles.ini nutzt, sondern -profile <pfad-zum-profil> könnte man damit verschiedene Firefox auf sich festlegen, wenn man die EXE umbenennt.


    HKEY_CLASSES_ROOT\Applications\firefox.exe\shell\open\command
    @="X:\Firefox\firefox.exe" "%1"


    HKEY_CLASSES_ROOT\Applications\firefox68.exe\shell\open\command
    @="X:\Firefox68\firefox68.exe" -profile <pfad68> "%1"


    HKEY_CLASSES_ROOT\Applications\firefox69.exe\shell\open\command
    @="X:\Firefox69\firefox69.exe" -no-remote -profile <pfad69> "%1"


    In diesem Zweig stehen u.a. notepad.exe, winrar.exe und andere, die man so ohne genaue Pfadangabe unter Start > "Ausführen" aufrufen kann.


    Beides liesse sich sogar verbinden, weil der Starter Parameter (zB Webseite) durchreicht


    HKEY_CLASSES_ROOT\Applications\firefox.exe\shell\open\command
    @="X:\Firefox Portable\firefoxstarter.exe" "%1"



    Nochmal auf das Tool "RegisterFirefoxPortable.exe" zu kommen - ich weiss nicht, was es tut, ich nutze kein NET Framework 3.5, welches benötigt wird. Kann ich nur unter Windows 7 testen.

  • Das hatte ich vor dem Schreiben ja noch gelesen und genau darauf beziehe ich mich ja. Bis v66 "firefox.exe" (egal welcher, ohne -no-remote) Aufrufe noch mit aufgefangen. Mit -no-remote hat es sich ja eh erledigt. Das Problem ergibt sich ja erst mit v67, dass Firefox selbst bei einer gestarteten Portable ein Profil im Benutzerordner erstellt bzw anfragt (Profilmanager). Und das muss der Portable Starter abfangen, nicht mehr Firefox.


    Die Portable als einmaliger Aufruf funktioniert, eine weitere Portable ja auch (-no-remote wird hinzugefügt), nur eben nicht mehr die Übergabe an eine laufende firefox.exe, weil die wegen der dedizierten Profile anders arbeitet.



    Das obige mit der Registry passt so nicht, es müsste sein
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\firefox.exe
    @="X:\\Firefox\\Firefox.exe"
    "Path"="X:\\Firefox"


    wird dann zu
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\firefox.exe
    @="X:\\Firefox\\FirefoxLoader.exe"
    "Path"="X:\\Firefox"


    (für die Portable, siehe Erklärung oben)
    Und der Code für den Starter muss erweitert werden, damit er bei Erkennung seine eigenen Instanz (siehe dein pastebin, BENE) eben auf Firefox mit gleichem Parameter für den Pfad starten.


    Um bei einem bildhaftem Beispiel zu bleiben, weil es bei vielen auch so passt:


    iCafee - Firefox Portable & Thunderbird Portable. TB (jedes andere beliebige Programm) kennt nur "firefox.exe" und weiss nicht, wo es liegt.
    Bislang reichte der Aufruf firefox.exe <link_aus_email>, jetzt muss bei einem Firefox Portable explizit das Profil angegeben werden, ansonsten landet der Aufruf als Profil im Benutzerordner. Problem dabei ist, dass weder der Ort von Firefox Portable (mitsamt Starter) bekannt ist noch der Ordner.


    Hilfreich wäre dann der Ort aus der Registry, den man setzen könnte (unter Berücksichtigung vorhandener Einträge), oder den anderen Program mitteil, wo der Portable Starter liegt.


    ---


    Nachtrag - der Code des Portable Starters erkennt schon seine eigene Instanz. Übersehen und zu kompliziert gedacht. Also müsste man nur den externen Aufruf an den Starter weiterreichen, nicht mehr an Firefox (siehe oben).


    Ich sehe grad noch einen Unterschied zum Code von Bene.


    D.h. der Code von Bene kann das gar nicht umsetzen, der macht nur einen neuen Tab auf wenn überhaupt.


    Was mir grad noch einfällt, der Starter stammt aus Zeiten, von noch kein multiprocess gab. Man müsste noch austesten, ob mit psapi nur die erste gefundene Instanz übergeben wird oder mehr als eine, ersteres wäre irgendwie schlecht.


    https://www.autoitscript.com/f…frompid-from-any-process/
    :idea:

  • Eben etwas recherchiert und das ist bei rausgekommen:


    - Parameter berücksichtigt
    - Firefox-Prozesse eingelesen
    - Pfad vergleichen
    - und ggf mit no-remote starten


    Update:

    - save/recover "addonStartup.json.lz4" für jedes Gastsystem

    Update2:

    - Struktur geändert

    - Option für Löschen(Standard)/Speichern der Datei (analog zu John T Haller bei portableapps.com)


    Hier wird multiprocess berücksichtigt, was bei psapi vorher nicht der Fall war.


    Jetzt fehlt nur noch die Festlegung auf den Starter als Ausgangspunkt für externe Aufrufe.


    #Code-Korrektur


    Funktioniert auf x86 und x64 (getestet unter Windows 8 und 10)
    Kann sich jeder mit AutoIt selbst zur EXE kompilieren
    https://www.autoitscript.com/site/

  • Update:

    - save/recover "addonStartup.json.lz4" für jedes Gastsystem


    Wegen

    Portable-Version FF - Aktivierte Add-ons werden nicht in Adress-Leiste angezeigt - nach PC-Wechsel


    In dieser Daten werden die pfade zu den Extensions gespeichert und das kann je nach Gastsystem abweichen und daher der beschriebene Effekt. Der Starter prüft und stellt ggf eine passende Ausgabe wieder her.


    Ganz Wichtig: Firefox Portable muss in solchen Fällen zwei Mal gestartet werden!


    Es gäbe noch die Möglichkeit, das LZ4 zu entpacken, müsste dann aber auch neu gepackt werden. Problematik dabei ist, dass Mozillas LZ4-Format abweicht vom Standard und auch eigene Konventionen verfolgt, die a) in zwei extra Tools ended und b) danach weiter modifiziert werden müssen. Derzeit sind meine eigene Fähigkeiten dahingehend begrenzt und deswegen nicht umsetzbar.

    Quelle: https://github.com/avih/dejsonlz4


    Update2:

    - Struktur geändert

    - Option für Löschen(Standard)/Speichern der Datei (analog zu John T Haller bei portableapps.com)