Bug 396291

I originally had it planned but there's no way to relate a window the extension sees to a native window X or Wayland see. The activities addon has a very crude heuristic to figure out which window is which. Something I experimented with but ultimately disabled for the 1.0 release.

It's definitely planned at some point in the future since many cool things (browser tabs in task bar, activity integration, audio indicator on right window, etc) only work once you have a window to work with.

There is an approach to integrate Firefox with activities based on automatic profile generation:

https://github.com/hellishnoob/activityfox

It has its flaws (lots of profiles, additional non-firefox window required and to hide, no way to change settings / extensions in all activity specific profiles at once) but maybe there is a chance to join this approach and the native component of plasma-browser-integration and to eliminate some flaws with the cooperation of native host and browser extension?

Is there still a plan to improve firefox integration and behaviours with activities. 

When restarting the computer (e.g. because of updates) with several activities and several firefox windows, those windows are restored more or less randomly to the different activities (for some reason some firefox windows almost always restore in the right activity but others are just restored randomly). 

This issue makes rebooting a bit of a pain.

(In reply to Gauthier from comment #3)
> When restarting the computer (e.g. because of updates) with several
> activities and several firefox windows, those windows are restored more or
> less randomly to the different activities (for some reason some firefox
> windows almost always restore in the right activity but others are just
> restored randomly). 

I have the exact same problem here. And because I'm using 12 activities x 4 desktops each with 20-40 firefox windows with a total of 60-100 tabs it makes it VERY cumbersome to reboot and even more so when the laptop runs out of battery. It takes around 10 minutes after reboot just to put windows in the right activity.

Same here!

Interestingly, the Firefox windows are normally placed on the correct workspace but not correct activity after reboot of the device or restart of the application.

So clearly there is a way for the KDE window manager to determine the correct place to a put a specific window, but apparently that mechanism isn't applied correctly to activities in the same way that it is to workspaces.

(In reply to Gauthier from comment #3)
> Is there still a plan to improve firefox integration and behaviours with
> activities. 
> 
> When restarting the computer (e.g. because of updates) with several
> activities and several firefox windows, those windows are restored more or
> less randomly to the different activities (for some reason some firefox
> windows almost always restore in the right activity but others are just
> restored randomly). 
> 
> This issue makes rebooting a bit of a pain.

I wanted to report that since Plasma 5.25 this behaviour seems much improved and all windows restore properly on reboot. I don;t know if any work was done on the firefox integration side of things or on the activity stack or on plasma but it works :)

Operating System: KDE neon 5.25
KDE Plasma Version: 5.25.4
KDE Frameworks Version: 5.97.0
Qt Version: 5.15.5
Kernel Version: 5.15.0-46-generic (64-bit)
Graphics Platform: X11

There is another wrapper for Firefox that is packaged in a few distros already (and easy to install yourself too):
https://gitlab.com/hook/activity-aware-firefox

I hope this feature gets implemented in Plasma proper, but until then, it is a work-around that worked well enough for me for a few years already. Then again, as one of the authors of this wrapper, I am biased.