1395510 - Session restore makes submitted github issue comments look as if they hadn't been submitted yet

Status: NEW

(Firefox :: Session Restore, defect, P2)

Description

[Markus Stange [:mstange]]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20170830220349

Steps to reproduce:

1. Log in to GitHub.
2. Open a GitHub issue in a Firefox tab, e.g. https://github.com/octocat/Hello-World/issues/332
3. Write and submit a comment to the issue.
4. Without closing the tab, restart your browser and restore the session.


Actual results:

In the restored tab, the submitted comment was not present, and the comment text was back in the textbox.


Expected results:

The restored tab should look the same as before Firefox was restarted.

Comment 1

[Marius Coman [:mcoman], Ecosystem QA]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Firefox: 57.0a1, Build ID 20170905220108

I have tested this issue on Windows 10 x64 and Mac 10.12, with the latest Firefox release (55.0.3) and the latest Nightly (57.0a1) build. I have managed to reproduce it using the steps provided in the description. Considering this, using the Mozregression tool, I have found a regression window:

Last good revision: c0ba5835ca489d15f8f170d5deb01f8dad92709a (2016-01-26)
First bad revision: 211a4c710fb6af2cad10102c4cabc7cb525998b8 (2016-01-27)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c0ba5835ca489d15f8f170d5deb01f8dad92709a&tochange=211a4c710fb6af2cad10102c4cabc7cb525998b8

Mike, can you please look over the pushlog and see if anything stands out?

Comment 2

[Mike de Boer [:mikedeboer]]

That's from a long time ago! It looks like a lot of e10s work was going on back then, so I'm forwarding the n-i to Mike Conley.
Mike, does something stand in the pushlog from comment 1?

Comment 3

[Mike Conley (:mconley) (:⚙️) (PTO July 21 - 25)]

I manually bisected this. SessionStore and e10s appear to be in the clear!

First regressing changeset:

5760541fd240	Patrick McManus — Bug 567365 - allow bfcache for no-cache/https r=jduell r=bz

Redirecting needinfo to mcmanus - perhaps he knows what's up here.

Comment 4

[Patrick McManus [:mcmanus]]

so that change just does what it says - which is what chrome does afaik. I can certainly see how it might have papered over a session restore issue for a while, but whatever the issue was would have shown up with http:// (instead of https://) for example anyhow.. sorry it makes the bisection hard.

Comment 5

[Mike Conley (:mconley) (:⚙️) (PTO July 21 - 25)]

(In reply to Patrick McManus [:mcmanus] from comment #4)
> so that change just does what it says - which is what chrome does afaik. I
> can certainly see how it might have papered over a session restore issue for
> a while, but whatever the issue was would have shown up with http://
> (instead of https://) for example anyhow.. sorry it makes the bisection hard.

Hm, okay.

So I guess this falls back into investigation - bisection didn't really help much.

I recommend someone stepping through ContentRestore.jsm during the restoration of the GitHub issues page to see which branch gets taken in restoreTabContent. We're likely showing a cached version of the page instead of reloading it, and the cache occurs before the comment is made and is never invalidated.

That sounds like an automated test case could be written for this.

Comment 6

[Ralf Jung]

I can confirm this problem to persist with 62.0b6.

It doesn't take session restore to trigger, closing the tab and un-doing closing shows the same problem. (Probably it's the same code?) I also verified that doing the same (closing, un-closing) in Chromium behaves as expected, this this is not a site issue.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 17 votes.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 8

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 9

[Smylers]

(In reply to BugBot (nomail) [:suhaib / :marco/ :calixte] from comment #8)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

If you mean “Is the bug still relevant?”, then yes it is: I've just followed the steps to reproduce and the buggy behaviour was still there in Firefox 116.0b1.

I commented on a GitHub bug per comment #0, then closed and unclosed the tab (Ctrl+W then Ctrl+Shift+T), per comment #6.