472096 - Session Restore incorrectly remembers and restores Google Reader state

Status: RESOLVED DUPLICATE of bug 447951

(Firefox :: Session Restore, defect)

Description

[Misak Khachatryan]

Session restore can't correctly remember and restore Google Reader state.

Steps to reproduce:
1. Open Google Reader.
2. Click on some subscription on the left.
3. Click on another subscription.
4. Close Firefox.
5. Run Firefox again to restore session.

Actual result: Firefox will restore state when first subscription selected.
Expected result: Last subscription should be selected.

I've tested this with Firefox 3.0.5, Fedora 10, KDE 4.1, which uses Gecko 1.9, and also on Seamonkey trunk, to which i'm porting session restore (port includes all current sessionstore and aboutsessionrestore patches for mozilla-central). Results are the same - looks like session restore don't remember google reader state at all.

Comment 1

[Simon Bünzli]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090104

WORKSFORME. What URL is in the address bar right before closing Firefox (and what feed was last selected) and what URL is restored after restoring the session (and what feed is then selected)?

For me, Google Reader's URL contains the feed's URL in the hash (sometimes after half a second) and that hash is used for reselecting the correct feed...

Comment 2

[Misak Khachatryan]

Attachment: sample sessionstore.js

It shows http://www.google.com/reader/view/#stream/user%2F00262137131437554830%2Flabel%2Fsport on location bar right before closing and after relaunch of Firefox it's http://www.google.com/reader/view/#stream/user%2F00262137131437554830%2Flabel%2Ffun

I'm attaching my sessionstore.js Also i want to mention that i'm using russian as a language for Google Reader, maybe it's important.

Comment 3

[Misak Khachatryan]

Sorry, forgot to mention: selected before closing - sport, after restore fun going selected

Comment 4

[Simon Bünzli]

Can you reproduce this with a clean tab (where you don't click around too often). This could be due to session history being limited to 50 entries. OTOH this could also be a Linux-only issue (see also bug 447951). Would you mind digging into the code to see if you can find out why we miss those latest URLs inside SessionStore (resp. if they're available through the tab's session history at all)?

Comment 5

[Simon Bünzli]

This is indeed linked to the session history limit of 50 entries. I can now reproduce this under Windows as well.