User Agent: Mozilla/5.0 (Android; Tablet; rv:24.0) Gecko/24.0 Firefox/24.0 (Nightly/Aurora) Build ID: 20130911123540 Steps to reproduce: 1. Open new tab 2. enter a url or search term, or select a page from Top Sites, Bookmarks, or History 3. follow links as you would normally, building up a history for the tab. 4. switch to another app, e.g. YouTube, perhaps to get a url to paste into a comment field. switching can occur by using he home button and launching it, or by using the recent apps button and switching to an already running backgrounded app. Firefox can be the only other app running, or one of many, it doesn't seem to matter. 5. use the other app for an undetermined, but short time 6. switch back to Firefox Actual results: Firefox will occasionally load/restore the first page visited within the current tab rather than the most recent one, forgetting all of the history asociated with the back and forward buttons, and any entered form data. When this happens, the Forward button will sometimes be displayed, but will do nothing. Expected results: Firefox should restore the most recently viewed page within the current tab, along with any back/forward button history and entered form data.

Brian, when the browser session restores shouldn't all forward and back history be restored for the current session? fitzmorrispr, in Firefox 26 (Aurora) and 27 (Nightly) you can opt to restore all tabs in customize settings.

(In reply to Aaron Train [:aaronmt] from comment #1) > Brian, when the browser session restores shouldn't all forward and back > history be restored for the current session? Yes, this sounds like a background kill, so all tabs/history should be restored regardless of settings. This bug actually sounds like a dupe of bug 915490 (assuming bug 915490 isn't limited only to private browsing). Given the fact that our session restore code has delays in place before saving state, and given the fact that these bugs manifest themselves after Firefox is backgrounded for an indeterminate amount of time, it's difficult to reproduce these bugs reliably (and I haven't been able to). Aaron, are you able to reproduce this? If so, a logcat dump would probably be useful.

I have yet to run into this in the wild. Can this be simulated through force memory pressure?

I've tried repro'ing using oom-fennec (https://hg.mozilla.org/users/blassey_mozilla.com/oom-fennec/), but everything works as expected.

I took a look at 915490, and it does indeed ound just like the problem I am experiencing. some things to note: I am running android 4.2.2, on a Samsung Galaxy Tab 2 7.0 WiFi Tabs other than the active one do not exhibit the issue Memory does not seem to be the cause, as noted, the number of other apps running does not seem to be a factor. the issue only crops up often enough to be a nuisance, and just rarely enough to lull me into a false sense of security. I suppose I can try aurora instead of the Play Store build, see what happens, though it sounds as though the setting mentioned is not really related.

Having tried Aurora on the same device, I am here reporting that this behavior is present in that version as well. If any of you gentlemen could tell me how to do it I would gladly collect log output for you. i have a terminal emulator on device (actually an ssh client with localhost access) and can run logcat. it is seriously aggravating to have to rewrite a comment three times because firefox forgot about it while you were finding a url to paste into it from another tab and/or app

Dissecting everything in comment 1, it sounds like there are two separate bugs here: 1) The last page opened before the browser was closed is not restored; instead, the first page in that tab's history is restored without back/forward history. 2) The state of the page (form data, scroll position, etc.) is not restored. When you say that this behavior is still present, are you referring to the first bug, the second bug, or both? Currently, not restoring the page's form data is (unfortunately) the expected behavior since we haven't yet implemented full state saving for session restore. If you're still seeing Firefox restore the wrong page, please post a logcat dump. All firefox logging goes through logcat, so a logcat dump immediately after Firefox dies/restores and results in the bug would be useful. To help reproduce this, you'll want a reliable way to make Fennec be killed and force a session restore. To do that, please do the following: 1) Download the binary in comment 4, push it to /data/local on your device (or /data/local/tmp if you don't have write access to /data/local) 2) Open Fennec to the state you want it to be in before the restore (i.e., open tabs with several pages of history) 3) Push home to put Fennec in the background (don't forget this step or step 4 may freeze your device!) 4) Run "adb shell /data/local/oom-fennec" to force Fennec to be killed 5) Reopen Fennec If you're able to reliably reproduce this bug using oom-fennec, please post the steps to reproduce here as that would be even more useful than a logcat dump.

Hi reporter, are you able to try out some of the above's steps and instructions?

Tab history being forgotten seems to be bug 1044556, which leaves this bug only with the form data issue.

The session store does save some form data (although it is currently hampered by bug 852267, bug 1261225 and bug 1044556, but those will soon be fixed), but only for the current page. Form data for other pages in a tab's history is only kept in memory and consequently lost when the tab is closed/zombified or Firefox killed.

Looking again at the original bug description, this seems more or less like bug 1044556's symptoms. For more comprehensive session history form data restoring, I've opened bug 1400578, since that issue affects Desktop's session store as well.