I run several Firefox instances with different profiles. They are started with
$ firefox --no-remote -P <profile>

However I was surprised to find out that after rebooting, this couldn't be restored. One Firefox instance starts, the other ones abort with error message.
Obsiously, the session doesn't save the paramteres.
I also tried with shell scripts, e.g. the script
"firefox-profile1" has the content

Code: Select all

firefox --no-remote -P profile1


Thus firefox runs inside a parent process without cmdline params.
But still no luck. Why that?

I looked into .kde/share/config/ksmserverrc, the only place where firefox is mentioned is

Code: Select all

[LegacySession: saved at previous logout]
clientMachine1=localhost
clientMachine2=localhost
command1=firefox
command2=firefox
count=2


What else can I try?

Did it ever work with parameters for other programs?

You can make a simple test, and run something else with a parameter, and check if it's restored the same way, or without. If not, then it's not the Firerfox's issue. If it should, it's probably a good feature to add.

No, params seem not to be supported by non-KDE programs.
That's why I created wrapper scripts with names like firefox-profile1. They don't need any params. However this is ignored by KDE. I guess it somehow filters the applications to be automatically started, so that only processes having a GUI are considered. The firefox-profile1 process in my case is the parent process of the firefox process itself.

It would be an acceptable solution if I can autostart this processes on login if they are placed in the correct desktops. How can I do that?

KDE uses a protocol known as the X Session Management Protocol (XSMP) to ask applications to save their state prior to shutdown. Wrapper scripts will not work in this case, as this querying is done through X itself - so going to the Firefox process itself directly.

Unfortunately it looks like Firefox's XSMP support does not extend to providing the appropriate restoring of seperate profiles.

didi_X8: You can file this bug to Mozilla's bug tracker then: https://bugzilla.mozilla.org

shmerl wrote:didi_X8: You can file this bug to Mozilla's bug tracker then: https://bugzilla.mozilla.org

I did so.

Thanks for suggestions.

Thanks for posting it. Bug record for reference: https://bugzilla.mozilla.org/show_bug.cgi?id=726490

I have the same problem.

Please continue to track this issue at it's upstream bug.