1294208 - When restoring a window, make the initial tab the selected tab

Status: RESOLVED DUPLICATE of bug 1351677

(Firefox :: Session Restore, defect)

Description

[Mike Conley (:mconley) (:⚙️)]

We do something kind of silly in SessionStore.jsm where if we're restoring a window, the initial tab is remote, and all other new tabs are non-remote (this is because unrestored background tabs are loaded in the parent process so that they cannot crash).

If the selected tab for the restored window is not the initial browser, this means that we're going to take a non-remote tab and then browse somewhere probably remote. This is wasted effort.

It might be simpler all around if we make it so that the initial browser and tab gets moved so that it becomes the selected browser / tab in the restored window. This way, we can avoid any kind of remoteness flips, since the initial browser starts remote now.

Comment 1

[Mike de Boer [:mikedeboer]]

Since we'd like the last selected tab to become the active tab and load immediately anyways, I think this is very reasonable to work on soonish.

Comment 2

[Mike de Boer [:mikedeboer]]

Mike, what's left to do here, taking your recent work in bug 1096013 into account?

Comment 3

[Mike Conley (:mconley) (:⚙️)]

(In reply to Mike Conley (:mconley) from comment #0)
> We do something kind of silly in SessionStore.jsm where if we're restoring a
> window, the initial tab is remote, and all other new tabs are non-remote
> (this is because unrestored background tabs are loaded in the parent process
> so that they cannot crash).
> 
> If the selected tab for the restored window is not the initial browser, this
> means that we're going to take a non-remote tab and then browse somewhere
> probably remote. This is wasted effort.

This is no longer true since bug 1256472, as all of those background tabs are being created as "remote" browsers.

> It might be simpler all around if we make it so that the initial browser and
> tab gets moved so that it becomes the selected browser / tab in the restored
> window. This way, we can avoid any kind of remoteness flips, since the
> initial browser starts remote now.

This kind of simplification is still a good idea but for a different reason - instead of avoiding a remoteness flip, we can avoid a tab switch if we move the initial tab to the selected slot.

And I'm actually doing that work in bug 1351677, so I'm going to dupe this bug to that one.