1749987 - Content from 9gag is missing when restoring session, it gets restored after fiddling with scrollbar

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Bogdan Maris, Desktop QA]

Attachment: Gif, showing the issue

Affected versions

• Firefox 96.0
• Firefox 97.0b2
• Latest Nightly 98.0a1

Affected platforms

• Windows 10
• MacOS 11.6
• Ubuntu 18.04

Steps to reproduce

1. Have only 9gag webpage loaded in a tab
2. Scroll to a position lower then the top of the page
3. Close Firefox
4. Reopen Firefox
5. Restore the previous session
6. Scroll down the website a bit then stop

Expected result

• The content is available after restoring the session.

Actual result

• The content of the website is temporarily missing from the page

Regression range

• Based on the builds affected this is not a recent regression, I will check ASAP if this is an actual regression or not.

Additional notes

• Users have to scroll up on the page and then down again for the content to show up again.
• Gif showing the issue is attached.

Comment 1

[Bogdan Maris, Desktop QA]

Aparently this is a recent regression caused by something from the following pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c9d499871dc8c87d1f138d1a954b675df5030a43&tochange=4243f988e94aa79dbdaa230ce86681b0a70eeebb

The Good build is one that does not remember the previous placement of the scroll elevator, it always restores at the top of the page so the content is correctly loaded. The Bad build has the scroll elevator remembered in the position where it was before closing Firefox.

Comment 2

[Dianna Smith [:diannaS]]

:Barret can you take a look?

Comment 3

[Barret Rennie [:barret] (they/them)]

I just looked at the pushlog and my commit (ac839ddcb82f572b49b6037a46e6d25c1dd7fdf5) was backed out in that pushlog (58229034be3be4661a3a3298af305106ff7f318e), so if the revision range is correct it is not due to this patch.

Comment 4

[Pascal Chevrel:pascalc (PTO until April 26)]

Bogdan can you still reproduce this bug? If you can, woud it be possible to get a better regression range? Thanks

Comment 5

[Bogdan Maris, Desktop QA]

(In reply to Pascal Chevrel:pascalc from comment #4)

Bogdan can you still reproduce this bug? If you can, would it be possible to get a better regression range? Thanks

I can still reproduce this issue using latest Nightly from today and the range from above is correct since after a bit more investigation I found out that fission.autostart pref is the one that seems to cause this:

• if the pref is set to false the scrollbar is always moved at the top of the page after restoring the session and this issue is NOT reproducible.
• if the pref is set to true the scrollbar keeps the position somewhere near the place it was before closing Firefox making this issue TO BE reproducible.

I see that the pref was enabled by default in the range from comment 0 in Bug 1732358. Nika can you please take a look at this?

Comment 6

[Nika Layzell [:nika] (ni? for response)]

Scrollbar restoration and session restore have changed a lot with Fission so it makes sense that this would reproduce specifically with that change. :bogdan_maris, could you also try the configuration where fission.autostart is false, and fission.sessionHistoryInParent is true?

Redirecting the ni? to :peterv who has been working on session history issues lately, and might have more context as to what might be causing this issue with SHIP.

Comment 7

[Bogdan Maris, Desktop QA]

(In reply to Nika Layzell [:nika] (ni? for response) from comment #6)

Scrollbar restoration and session restore have changed a lot with Fission so it makes sense that this would reproduce specifically with that change. :bogdan_maris, could you also try the configuration where fission.autostart is false, and fission.sessionHistoryInParent is true?

Sorry for the late reply, indeed this is also reproducible with fission.autostart set to false, and fission.sessionHistoryInParent set to true.