447951 - Gmail displays wrong/previous URL on session restore after heavy usage (50 hash changes)

Status: RESOLVED FIXED

(Firefox :: Session Restore, defect)

Description

[Ryan Fugger]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008071719 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008071719 Firefox/3.0.1

Sometimes when I shut down Firefox with Gmail (v2) in the inbox, it restores at the email I had been reading/composing previously before going to the inbox and shutting down.  

I have session restore enabled by default in preferences.

Reproducible: Sometimes

Steps to Reproduce:
1. Read a particular email in gmail.
2. Go to gmail inbox.
3. Close firefox.
4. Start firefox.
Actual Results:  
Gmail displays the email I was previously reading (in step 1).

Expected Results:  
Gmail should display the inbox.

I'm fairly sure this was happening in FF2 as well.

Comment 1

[Simon Bünzli]

(In reply to comment #0)
> 1. Read a particular email in gmail.

Any clue what should be particular about that email?

Has this ever happened again? If so, could you please install the Session Manager extension from <https://addons.mozilla.org/firefox/2324> and have it make backups of all your sessions. When it happens again, please immediately restore the backup and make sure that the session repeatedly restores the email instead of the inbox. I'd like to have a look at that specific session file (to determine whether the wrong URL has been saved to start with or whether it's a different issue).

Comment 2

[Ryan Fugger]

> Any clue what should be particular about that email?

It is the last email I read.  Recently, it actually went back to the last gmail search I did.  The pattern seems to be that it goes back to the previous gmail page I was looking at before going back to the inbox and closing firefox.  This doesn't happen every time, but about 30% of the time.  I'm still trying to pinpoint the set of conditions that causes it.  I'll try using session manager and report back.  Thanks.

Comment 3

[Simon Bünzli]

So, Ryan sent me a session where the observed issue happened. To me it looks like either Firefox is shut down slightly too quickly (before the inbox has been completely displayed) or Firefox didn't shut down properly (maybe due to an extension).

In any case, the history entry for the inbox is missing from sessionstore.js - as if our session state hadn't been updated for a last time - and can't thus be restored.

Ryan: Would you mind disabling all your extensions for a while (in case you use any at all, that is) and see if the issue still happens?

Oh, and how do you actually close Firefox?
You don't get any "Firefox has crashed" prompts on startup, do you?

Comment 4

[Ryan Fugger]

I'm definitely not shutting down Firefox quickly after loading the inbox -- at least 5 minutes, and sometimes over an hour.  I close Firefox with the 'X' in the top right corner of the window.  I do not get any "Firefox has crashed" prompts at startup.  

I *do* notice that sometimes a gmail page does not seem to ever finish loading -- the busy icon at the right end of the menu bar keeps spinning indefinitely when I'm on that page, but I don't notice that very often, and when I do I nearly always refresh the gmail page until it does finish loading properly.  I do not think this is the issue here, but it might be related.

Does a page not get added to the session until it has completed loading?  What about if I nagivate away from a page in the middle of it loading -- does it get added to the history for that tab in the session, or is it left out?  One thing about the session I sent Simon is that it was missing not just the last page that should have been in the gmail tab, but that last *three* pages (inbox, email, inbox), so even if the last page didn't load completely, it seems logical that the other two ought to have been added when I navigated away from them.

I run a few extensions.  The only ones that I have run consistently while I've experienced this problem are Adblock Plus, Easy DragToGo/QuickDrag/Super DragAndGo, and Firebug.  I'll try disabling everything except Session Manager and see if I can still replicate the problem.

Comment 5

[Ryan Fugger]

Bug confirmed with all extensions disabled except Session Manager (not installed when bug originally occurred).  I archived an email, sending me back to inbox, did some browsing in other tabs, and then closed the browser.  When I restarted, the email I had previously archived was displayed in the restored gmail tab.

One thing I haven't mentioned is that often another Firefox user profile gets opened on my machine (using 'firefox -profilemanager') in between closing my gmail profile and restarting it later.  In fact, I can't be sure that this bug occurs when another profile hasn't been opened in between.  I didn't think it would be relevant, but maybe it is...?

Comment 6

[Simon Bünzli]

The profile manager shouldn't interfere with what's saved to disk to be restored later. My guess is that this is a a Linux specific shutdown related issue that I won't be able to reproduce on my Windows box.

One further thought I just had, though: With Session Manager disabled, what happens when you close a tab containing Gmail and then restore this very same tab through History -> Recently Closed Tabs? Does it restore the correct emails/inboxes/etc. in this case?

Comment 7

[WildcatRay]

Bug 450595 may have some clues for resolving this bug.

Comment 8

[Simon Bünzli]

(In reply to comment #7)
It doesn't - unless you're telling me that you no longer see the issue with bug 450595 fixed.

Comment 9

[WildcatRay]

(In reply to comment #8)
> (In reply to comment #7)
> It doesn't - unless you're telling me that you no longer see the issue with bug
> 450595 fixed.
> 

Perhaps. I have tried a few times now and NOT seen the "previous" email message. The gmail inbox has been coming up, as expected.

As to referring to the other bug, I put it forth as perhaps the underlying cause may be the same for both bugs as is seems both are dealing with the session save/restore routine of the browser and how it handles an AJAX application, gmail, when first saving and then restoring a browser session.

Just trying to help.

Comment 10

[Simon Bünzli]

(In reply to comment #9)
> Perhaps. I have tried a few times now and NOT seen the "previous" email
> message. The gmail inbox has been coming up, as expected.

Ryan: In case you feel at home with editing text files: Could you copy the lines starting with + signs from attachment 333916 [details] [diff] [review] to the appropriate place in nsSessionStore.js in Firefox' components directory (there's plenty of context in the patch; and make sure to not copy the + signs themselves)? IOW: Apply the patch and then try and see if your bug reappears ever again.

> Just trying to help.

Thanks.

Comment 11

[Ryan Fugger]

OK, I patched nsSessionStore.js.  Will report back in a few days.

Comment 12

[Ryan Fugger]

The bug still happens, even with the new nsSessionStore.js.

Comment 13

[WildcatRay]

When I was repeatedly enabling/disabling/reenabling extensions the other day, I was seeing this bug. Perhaps in using the add-on manager restart button there may be a pretty consistent way to reproduce this bug. I'll keep my fingers crossed for you all.

Comment 14

[Ryan Fugger]

This bug just appeared in a non-gmail tab (facebook), so it is not necessarily gmail-specific.  It did appear in gmail at the same time as facebook (both tabs displayed previous URLs when I just started up.)

I seem to get this bug most often when I shut down a different user profile and immediately restart firefox in the gmail/facebook profile.

Comment 15

[Simon Bünzli]

This also happens in Google Reader and other similar AJAX applications and only happens when a tab is heavily used (at least 50 changes between messages and folders). Confirming.

Comment 17

[Simon Bünzli]

Attachment: ignore chached URLs when session history is full

The correct way to do this would be to reset __SS_data on anchor navigation as we already do on page load. Unfortunately, anchor navigation isn't really detectable, so we'll have to rebuild always once session history has filled up (which should rarely happen in real life and not be noticeable at all, performance-wise).

Comment 18

[Dietrich Ayala (:dietrich)]

Comment on attachment 355438 [details] [diff] [review]
ignore chached URLs when session history is full


>+    // XXXzeniko anchor navigation doesn't reset __SS_data, so we could reuse
>+    //           data even when we shouldn't (e.g. Back, Back, different anchor)

Back, Back

>     if (history && browser.parentNode.__SS_data &&
>+        browser.parentNode.__SS_data.entries[history.index] &&
>+        history.index + 1 < this._sessionhistory_max_entries && !aFullData) {
>         browser.parentNode.__SS_data.entries[history.index] && !aFullData) {

hrm?

Comment 19

[Simon Bünzli]

(In reply to comment #18)
> hrm?

We ensure that session history isn't filled up (history.index == this._sessionhistory_max_entries - 1). Would you prefer some arithmetic shuffling around or do you have more basic concerns?

Comment 20

[Dietrich Ayala (:dietrich)]

shouldn't the second line containing "!aFullData" be removed?

Comment 21

[Simon Bünzli]

Attachment: updated to comments

(In reply to comment #20)
> shouldn't the second line containing "!aFullData" be removed?

Now that you mention it... removed.

Comment 22

[Dietrich Ayala (:dietrich)]

Comment on attachment 356470 [details] [diff] [review]
updated to comments

r=me, thanks!

Comment 23

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/84d5137a9b6b

Comment 24

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 356470 [details] [diff] [review]
updated to comments

a191=beltzner

Comment 25

[Dão Gottwald [:dao]]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b72d2f32b88e