1668882 - Last tab opened is not restored after restart

Status: RESOLVED DUPLICATE of bug 1672175

(Core :: DOM: Navigation, defect, P3)

Description

[Mike Conca [:mconca]]

With Fission enabled, the last tab opened is not restored to the correct URL.

STR

1. Create a new profile
2. Leave the two default pages open (first run, privacy notice) - not sure if strictly necessary
3. In about:prefs, enable automatic session restore
4. In about:config, set both fission.autostart and fission.sessionHistoryInParent to true
5. Open a new tab
6. Enter any URL, wait for page to load
7. Restart browser

Expected Results
Browser opens and the URL entered in step 6 above is loaded

Actual Results
Browser opens and shows the new tab page (pocket stories, etc.)

Comment 1

[Neha Kochar [:neha]]

Unable to repro with these STR. Mike, is this still reliably happening for you?

Comment 2

[Mike Conca [:mconca]]

(In reply to Neha Kochar [:neha] from comment #1)

Unable to repro with these STR. Mike, is this still reliably happening for you?

Kinda...

The behavior has changed, and isn't as consistent. For step 6, use espn.com and then continue, adding:

8. espn.com site probably restored with focus. Close that tab.
9. Open a new tab, go to espn.com again
10. Restart browser

Most of the time now, that espn.com tab never restores, but twice it restored simply to the new tab page.

Comment 3

[Neha Kochar [:neha]]

I don't know what's different but I'm still unable to repro with my default profile as well as with a new fission profile.

Comment 4

[Neha Kochar [:neha]]

Mike, since I'm unable to repro, I'm going to ask you to try with only fission.autostart (it internally implicitly uses SHIP codepath now) and see if you can still repro. Thanks for your help. :)

Comment 5

[Mike Conca [:mconca]]

Attachment: Fission New Tab.mp4

I can definitely still reproduce it on the current Nightly, although this time I had to repeat the close tab-->open new tab-->go to URL-->restart sequence twice to get it to happen.

I made a video of what I'm doing, in case it provides any insight (like I'm doing something odd). The tool I used to record doesn't show menus or modal dialogs, so you'll notice about:preferences "magically" appears when I select it from the invisible menu, and the browser "magically" restarts after I set the Fission pref to true because it asked to restart and I said yes.

Comment 6

[Mike Conca [:mconca]]

Also, this happening on Windows 10, in case the platform makes a difference.

Comment 7

[Chris Peterson [:cpeterson]]

Mike, can you still reproduce this bug?

This broke because the fission.sessionHistoryInParent behavior was taking effect immediately, but fission.autostart didn't take effect until after Firefox restarts. Peter recently changed sessionHistoryInParent to only take effect on restart.

btw, the sessionHistoryInParent functionality is automatically enabled (but not the fission.sessionHistoryInParent pref, so you should ignore that pref) when fission.autostart is enabled.

Comment 8

[Mike Conca [:mconca]]

(In reply to Chris Peterson [:cpeterson] from comment #7)

Mike, can you still reproduce this bug?

Yes, this still reproduced on the latest Nightly. Current STR:

1. Create a new profile
2. Leave the two default pages open (first run, privacy notice) - not sure if strictly necessary
3. In about:prefs, enable automatic session restore
4. In about:config, set fission.autostart (restart browser when prompted by Firefox)
5. Open a new tab
6. Enter espn.com in URL bar, wait for page to load
7. Restart browser
8. espn.com site probably restored with focus. Close that tab.
9. Open a new tab, go to espn.com again
10. Restart browser

The espn.com page will often be either the new tab page, or won't even restore at all.

Comment 9

[Mike Conca [:mconca]]

I played with this some more. On step 9, I can most successfully repeat this if I close the browser immediately after the throbber stops throbbing in the espn.com tab. This site has a lot of iframes, and visually it looks like the throbber stops when the main content is loaded but several iframes are still waiting for content. Maybe a clue?

Comment 10

[Neha Kochar [:neha]]

Doesn't need to block the experiment launch. I'll try reproducing again tomorrow with these STR. Thanks mconca!

Comment 11

[Neha Kochar [:neha]]

I still can't reproduce. Randell, can you try and repro and maybe figure out the problem here?

Comment 12

[Randell Jesup [:jesup] (needinfo me)]

Reproduces easily - appear to be a dup of bug 1672175 -- basically there's a ~15 second timer which saves the state; the state is not being saved on a clean exit. So repro depends on if 15 seconds (or whatever) has passed since you made a history change (which should be when you start loading the page IIRC).