348857 - Firefox fails to reload cached form fields when directly going back to an intermediate anchor in the history

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[David Bloom]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1b1) Gecko/20060707 Firefox/2.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1b1) Gecko/20060707 Firefox/2.0b1

Testcase: http://bloomd.home.mchsi.com/fx-form-bug.html
The word "PASS" should appear in the textarea after about 5 seconds.

I have verified this problem in:
* Firefox 2.0b1 on Windows Server 2003
* Firefox 1.5.0.6 on MacOS X 10.4.7 (PowerPC)
* Firefox 1.5.0.3 on Linux (Knoppix 5.0)

Basically, if a page has multiple history entries (due to multiple anchors/fragment identifiers being in the history stack for the page), then returning to a history entry other than the very first or very last entry will cause previously entered form values to be lost.

This is not just an annoyance to users who expect the form fields they fill in to be remembered, but also to developers of web applications that use a textarea to cache session variables that are unique to the specific instance of the page in the top level browsing context's history (see http://codinginparadise.org/weblog/2005/08/ajax-tutorial-saving-session-across.html#). If the web application uses this as well as URL fragment identifiers (anchors) to allow pages to be bookmarked and shared, then the textarea cache storage will be cleared if the user uses the back button's dropdown menu to return to the web application.

Reproducible: Always

Steps to Reproduce:
(Note: steps 7 and 8 are not required to reproduce the bug)

1. Go to http://www.google.com/
2. Type "text" in the form field
3. Click on the location bar or press CTRL+L (or Command-L) to set focus to the location bar.
4. Add "#foo" to the end of the location, so that it is "http://www.google.com/#foo". Press ENTER to add this location to the history.
5. Remove "#foo" from the location and add "#bar" to the end of the location, so that it is "http://www.google.com/#bar". Press ENTER to add this location to the history.
6. Set the location bar to "http://www.example.com". Press ENTER to leave Google and go to example.com
7. Click on the Back button. The form field will still be correctly filled in.
8. Click on the Forward button to return to example.com
9. Right click on the Back button. Click on the *second* "Google" item in the pop-up menu.
10. When Google reloads, the form field will be blank, even though it should still read "test".
Actual Results:  
The form field was blank

Expected Results:  
The form field should still have the value "test"

Comment 1

[David Bloom]

I can also verify this problem on the 8/20/2006 nightly build of Minefield (running on Windows Server 2003).

Comment 2

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1b2) Gecko/20060908 BonEcho/2.0b2 ID:2006090803

I can confirm your repo steps are accurate, but I am hesitant to set this bug to NEW since I don't actually know if it _is_ a bug. But I'll take the liberty of CC'ng some people who have delt with history:session bugs in the past in the hope they won't get mad at me and will have more to say on the matter :)

Comment 3

[David Bloom]

Verified bug in Firefox 2.0 final, as well as in trunk as of 10/26/2006 (both tested on Windows Server 2003).

Comment 4

[David Bloom]

I've sent this bug into the Opera folks as well (Opera bug 247038) because Opera has the same problem.

Comment 5

[David Bloom]

Still unfixed, as of Firefox 3 nightly 2007080104 (tested on OS X).

Any chance this can be fixed by the Firefox 3 release?

Comment 6

[David Bloom]

This has now been fixed in Opera 9.5 ("Kestrel") builds.

This bug has been here a year and is still unconfirmed by Mozilla. Here are browsers without the bug or with it fixed:
* IE
* Opera
* Safari
Here are browsers that apparently haven't even decided if this IS a bug:
* Mozilla

Just a friendly status update ;-)

Comment 7

[Aleksei Perepelkin [:chaos]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007110515 Minefield/3.0a9pre

On some pages works, on others not. On google input resets when returning to it even from 1 level back.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Jesse, this isn't a form controls problem.  This is a session history issue.  The state is only stored on the session history entry for the last scroll (the one before we navigate away from the page).  So if we go directly to one of the other scroll states it doesn't have anything to restore.

Solving this would probably involve rearchitecting state restoration so that the state is something that the shistory creates and owns (in some sense) instead of something it's handed.  That way all the scroll states could share the same state easily.

Comment 9

[David Bloom]

IE doesn't have this bug becuase it doesn't show fragment identifier history entries as separate items in the back/forward button dropdowns.

Perhaps Firefox should match IE's behavior on this? Or, only show fragment identifier changes in the dropdown if they are from the current page?

I have spent a long time investigating this bug and trying to work around it. It affects my and many other history libraries. Fragment identifier-based history with hidden <input> storage is now being used on many mainstream sites. I think this bug is very important, and it would be a shame if some sort of fix or workaround doesn't make it into Firefox 3.