1067687 - Tabs gone after Nightly update

Status: RESOLVED WORKSFORME

(Firefox for Android Graveyard :: Session Restore, defect)

Description

[liam]

User Agent: Mozilla/5.0 (Linux; Android 4.4.4; Nexus 5 Build/KTU84P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.117 Mobile Safari/537.36

Steps to reproduce:

Installed Nightly update. 
Opened browser.


Actual results:

Previously opened tabs were gone.


Expected results:

Previously opened tabs should've opened when browser was restarted.

Comment 1

[Aaron Train [:aaronmt]]

You can restore previously opened tabs in the recent tabs panel in Nightly.

Comment 2

[liam]

(In reply to Aaron Train [:aaronmt] from comment #1)
> You can restore previously opened tabs in the recent tabs panel in Nightly.

>

That's was never an option. I had close to 190 tabs.
I've browsed to root and found the sessionstore.bak which has the correct tabs but I'm not able to simply replace the sessionstore.js. Is there some signing involved?

Comment 3

[Kevin Brosnan [Ex-Mozilla]]

Is the file valid json? I forget if we use the same format as desktop, one thing to try would be to create a clean desktop profile and see if desktop will accept it as sessionstore.js. The file needs to be owned by the same user as whatever Android assigned Nightly to.

Comment 4

[liam]

(In reply to Kevin Brosnan [:kbrosnan] from comment #3)
> Is the file valid json? I forget if we use the same format as desktop, one
> thing to try would be to create a clean desktop profile and see if desktop
> will accept it as sessionstore.js. The file needs to be owned by the same
> user as whatever Android assigned Nightly to.

As near as I can tell (using a text file viewer), it looks correct. It should be owned by me as it was saved as a .bak, and the only change I made was changing the extension to .js (as root).
Using a root browser it says owned by app_93 (the same as the sessionstore.js I'd overwritten), but when I relaunch the browser the sessionstore I'd renamed gets renamed to .bak, and a new sessionstore is created.
I'll try your idea with the desktop to see if it works.

Comment 5

[liam]

(In reply to Kevin Brosnan [:kbrosnan] from comment #3)
> Is the file valid json? I forget if we use the same format as desktop, one
> thing to try would be to create a clean desktop profile and see if desktop
> will accept it as sessionstore.js. The file needs to be owned by the same
> user as whatever Android assigned Nightly to.

Ok, it opens correctly on the desktop (also linted it).
Any ideas about how to get it working on android?
BTW, apparently you can't log on to Persona from Nightly on Android (says you need a modern browser like FF). It does, however, work from chrome on android.

Comment 6

[Kevin Brosnan [Ex-Mozilla]]

I'm not sure what the next steps are here. Brian I believe is the session restore expert. Liam would you be willing to share the session restore file with a developer?

Comment 7

[Brian Nicholson (:bnicholson)]

I'm curious why this isn't working. Some options:

1) Check logcat for errors (grep for "Gecko").
2) Send over your sessionstore.js and I can try to reproduce. Given that it contains 190 tabs, there's a good chance it contains sensitive data, so this might not be a good option.
3) I can post custom Fennec builds with verbose logging. You can copy your sessionstore.js into those profiles, then upload the logs.

Liam, please let me know which of these you're willing to try!

Comment 8

[liam]

Attachment: fennec.log

Hi all,

Sorry for the long pause between responses. For some reason I didn't receive any email for the subsequent responses...

So, why don't we give logcat a shot first?

Comment 9

[liam]

Attachment: log when sessionrestore.bak was renamed to sessionrestore.js

I probably should've given you a bit more context for the log in the first post.

That earlier log was the result of deleting the sessionstore.js and leaving only the .bak.

This log is the inverse.
I thought this might be useful as I read a bug report from a few years ago for fennec that said that the browser reacted differently depending on whether .bak or .js was present. In particular the behavior was changed, iirc, so that on clean exits the .js was erased, and it's existence meant a an early exit had occured.

Comment 10

[Brian Nicholson (:bnicholson)]

Thanks for posting. That second attachment is interesting as it means something might be wrong with the format of the file. Could you post the beginning contents of your sessionstore.js file, up until the first URL?

For example: {"windows":[{"tabs":[{"entries":[{"url":"about:home"...

And this with your 190 tab sessionstore.js file that works on desktop, right?

Comment 11

[liam]

Attachment: snippet of sessionstore

Yeah, I noticed that as well but it didn't make sense to me as I both linted the json and, more importantly, was able to recover the tabs on the desktop. However, I'd still like to be able to recover then on the phone:)

Comment 12

[Brian Nicholson (:bnicholson)]

Well, I don't see anything wrong with that snippet, and if the linter validates it and it works on desktop, it's probably not the file itself. Perhaps we're running out of memory trying to parse that blob.

I'll see if I can try recreating a similar session file. Liam, what's the file size of this sessionstore.js?

Comment 13

[liam]

262.3KB

Comment 14

[Brian Nicholson (:bnicholson)]

That's not too big, so I'm not sure memory would be a concern. NI'ing myself to test this.

Comment 15

[liam]

Hi again,

So, this just happened to me, again....TWICE, in the last few days. Both times after an update, but I didn't lose the session until I actually "closed" the browser (swiped away from the apps overview screen).
Perhaps, as a stop gap, the mozilla sync service could allow state rollbacks? As it is, as soon as this happens, sync becomes useless for that session.

Comment 16

[Jan Henning [:JanH]]

Short of a file format upgrade blunder as in bug 1379374, there's nothing special about app updates when compared to a normal OOM kill.

I fear that the current state still isn't entirely foolproof, but as the last comment here still predates bug 1190627 I'm closing this for now.