[Affected versions]:

• Firefox Nightly 77.0a1 Build ID 20200414214610;

[Affected Platforms]:

• Windows 10
• Mac OS 10.15.3
• Ubuntu 18.04 x64

[Prerequisites]:

• Have an en-US locale build;
• Have the “browser.search.region” pref set to “US”;
• Have the “browser.tabs.remote.separatePrivilegedContentProcess” pref set to “true”;

[Steps to reproduce]:

1. Open the browser with the profile from prerequisites.
2. Open about:newtab page.
3. Scroll down the page and click on a popular link.
4. Go back to about:newtab.
5. Observe scroll position.

[Expected result]:

• Scroll position is in the Popular links area.

[Actual result]:

• Scroll position is not maintained. (scroll position is on top of the page)

[Regression range]:

• Last good revision: 3004bc7597a088e181fbcb9a9044b8d952e9d45f

• First bad revision: 5b47cfcab1554c89400b7a6299ff0cabac4bda0c
  Pushlog:
  https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=3004bc7597a088e181fbcb9a9044b8d952e9d45f&tochange=5b47cfcab1554c89400b7a6299ff0cabac4bda0c

• Seems like Bug 1617983 stands out and might caused this behavior;

[Additional notes:]

• Reproducible also while clicking a Recommended by Pocket/ Highlight cards and coming back to the page;
• No matter the value of the “browser.tabs.remote.separatePrivilegedContentProcess” pref (true/false) we encounter an old issue that stands for not keeping the scroll position only the first time a user comes back to the page.

@mconley can you please take a look on this?

This looks like a general problem that has existed for a while - when we do process flipping, we don't seem to restore scroll position correctly after the navigateAndRestore step of the process flip.

I'm going to see if this has always been a problem, or is a result of recent Fission efforts in SessionStore.

So, I think this is a general problem where when process flipping, we don't restore the correct layout history state.

STR:

1. Enable Fission (fission.autostart to true) and restart the browser
2. Visit https://www.mikeconley.ca/blog
3. Scroll halfway down the page
4. In the URL bar, type in https://www.mozilla.org and press Enter
5. After the mozilla.org page, click on the back button

ER:

The scroll position on mikeconley.ca should be restored.

AR:

The scroll position on mikeconley.ca is not restored.

Interestingly, if I cause a navigation to occur in the mikeconley.ca domain / process after I've changed the scrollposition, then this scroll position is correctly restored. Here are those steps:

STR:

1. Enable Fission (fission.autostart to true) and restart the browser
2. Visit https://www.mikeconley.ca/blog
3. Scroll halfway down the page
4. In the URL bar, type in https://mikeconley.ca/blog/about/ and press Enter
5. Click back. Note how the scroll position is restored.
6. In the URL bar, type in https://www.mozilla.org and press Enter
7. After the mozilla.org page, click on the back button

Using these steps, the correct scroll position is restored... what's going on here? AnnyG, do you know? Or do you know who I should ask?

Bonus question - is there a known bug for failing to restore scroll positions when navigating like this? I feel like this sort of thing would have been noticed by now...

@mconley Thanks for looking over this so quickly!
I, also, can confirm that after trying the STRs you provided above, happens as you mentioned.

This is probably not worth fixing right now until we land changes for rebooting session history in the parent. bug 1570255 might be of interest but it's only the beginning of the reboot :)

https://hg.mozilla.org/mozilla-central/rev/d22dbc3857ec

I have verified that the issue is no longer reproducible on Firefox Nightly 77.0a1 (Build ID) using Windows 10 x64, Linux Ubuntu 18.04 and Mac OS 10.15.
Scroll position is maintained for the second time the user comes back to the page, and after.