637624 - Session restore not compatible with one-profile-per-activity setup in KDE

Status: RESOLVED WORKSFORME

(Firefox :: Session Restore, defect)

Description

[Robin Green]

KDE 4.6 has introduced the ability to start and stop activities during a desktop session. Activities are a bit like virtual desktops. When an activity is stopped, standard X session management is used to tell the applications running inside that activity to save a session and terminate. When that same activity is restarted, the applications are told to start using that session information, just as if they had been started at login.

However, this doesn't work with Firefox. The first reason it doesn't work is that Firefox by default uses a single-process execution model, unlike Konqueror, which doesn't allow you to independently stop and start individual Firefox windows. So, my idea was to create a different Firefox profile and running instance for each activity (as necessary). I hoped that this would have allowed each Firefox instance to be stopped and started independently (thus *potentially* conserving system resources, which is a major goal behind stoppable activities). I expected to have to create Firefox profiles manually - no problem - but I didn't expect the sessions to fail to restore. If an activity containing a different Firefox profile is stopped and restarted, Firefox just opens a new window in the existing running process (i.e. -no-remote is not used), and goes to the home page - discarding the previous session.

This bug was previously filed in the KDE bug tracking system by someone else:
https://bugs.kde.org/show_bug.cgi?id=264708
but a KDE developer said it was a Firefox bug.

Side note: Indeed, none of the Firefox options for profiles appear to work without -no-remote, either. (Does *any* Firefox option work without -no-remote when there is already a Firefox instance running in the same session?)

Comment 1

[Robin Green]

If I hack the ksmserverrc file to add -no-remote to the command line for the stopped instance, that doesn't work either, because firefox starts with the wrong profile. Restoring a session from a different profile does not work. (Should I file a separate bug for that?)

Comment 2

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(In reply to comment #1)
> Restoring a session from a different profile does not work.

And likely never will. Profiles are meant to be independent and not share data.

Anyway, I think this might be a larger problem of the lack of support for Activities, not just session restore. From what I'm understanding of Activities, it's trying to be like fake user accounts without having separate accounts. Which is going to be confusing for many profile based applications.

Comment 3

[Ilia K.]

I think the summary should be more general, like "Support KDE activities in Firefox". Anybody want to change it?

Probably, a relatively small hack into Session Manager[1] Firefox extension can add support for stopping/restoring activity.

[1] https://addons.mozilla.org/en-US/firefox/addon/session-manager/

Comment 4

[bugtracker]

A possible workaround is provided here:
https://bbs.archlinux.org/viewtopic.php?id=137941

Comment 5

[Adrian Florinescu [:aflorinescu]]

Assuming that my understanding of this issue is correct , then accounting for the dedicated profile(one profile per install) should solve this problem.

I am going to exemplify with my workflow with KDE 5.18.7, which requires me to have multiple versions of Firefox installed and running in the same time. So, I have 3 main versions that I always keep up-to-date as reference: nightly, beta, release, with 3 install locations, to simplify lets say the 3 installs are under /home/user:

• /home/user/release
• /home/user/beta
• /home/user/nightly

By default, running all 3 versions without any parameters will trigger creation of dedicated profiles:

• /home/user/release will start with profile default-release
• /home/user/beta will start with profile default-beta
• /home/user/nightly will start with profile default-nightly

You can define what the default profile for the running install should be from the about:profiles.

Now, assuming that I would like to have 3 activities: Work-Nightly, Work-Beta and Work-Release, which run the right version with the right profile, I would just need to start the correct firefox in the right activity. The correct version with the correct profile and the right session-restore will always be in the right activity.

The above will work with multiple instances of release for example, as long as you have an install for each. Note that snap builds do function a bit different in regards to profile management, so that would need a little more tweaking.

Based on the above, I will mark this issue as WFM.