Closed Bug 472096 Opened 16 years ago Closed 16 years ago

Session Restore incorrectly remembers and restores Google Reader state

Categories

(Firefox :: Session Restore, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 447951

People

(Reporter: misak.bugzilla, Unassigned)

References

()

Details

Attachments

(1 file)

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.
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...
Whiteboard: [worksforme?]
Attached file sample sessionstore.js (deleted) —
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.
Sorry, forgot to mention: selected before closing - sport, after restore fun going selected
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)?
Whiteboard: [worksforme?]
This is indeed linked to the session history limit of 50 entries. I can now reproduce this under Windows as well.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: