Bug 10161 – REGRESSION: form state not restored when going back to a page with frames

• Status: NEW
• Component: Frames

[Trey Matteson]

Go to the above URL.  Click on "forms" link on the left to load the main frame with some content including forms.  Type something in one of the text fields.  Go to any other page (I did www.cnn.com).  Go back.  The form state is not restored.

Note the if you scroll before going to cnn.com, the scroll position is restored when you go back.  This also works if there are no frames involved.

This works in 10.4.7 (and my guess is it worked in a bunch of previous releases), but fails in TOT
  Last Changed Rev: 15648
  Last Changed Date: 2006-07-27 02:22:16 -0700 (Thu, 27 Jul 2006)

[Trey Matteson]

I will be checking in some automated tests that are blocked by this bug.  When fixed, look through LayoutTests/http/tests/navigation/*disabled for this bug number.

I cannot reproduce in TOT.

[Matt Perry]

I just noticed this as well.  From stepping through the code, it looks like the documentState is available on the HistoryItem initially when you navigate back, but is overridden with empty data before it is restored.

Here's what I think is happening.  Since the frames don't exist yet when you hit Back, they need to be created.  FrameLoader::init() is called, creating an empty document for its new frame.  At this point, FrameLoader::restoreDocumentState() is called, to restore the document state of the original forms into the empty document.  This fails because the load is still provisional, and restoreDocumentState only grabs from the currentHistoryItem, which is NULL.

Then, when the Back navigation is committed, the document state for the empty document is saved onto the HistoryItem corresponding to the subframe with form data.  Shortly after, restoreDocumentState is called again, but by this point the documentState is already clobbered.