207312 - Forms in frames don't remember values

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[jag (Peter Annema)]

Reassign as needed.

When you fill in a form in a page, go to another page, then hit the back button,
the values you filled in / changes you made should be restored.

If you do the same for a form in a frame, the values are lost.

Attaching testcase.

Comment 1

[jag (Peter Annema)]

Attachment: frame for frameset testcase

Comment 2

[jag (Peter Annema)]

Attachment: frameset for testcase

Comment 3

[jag (Peter Annema)]

Steps to reproduce:

1) load attachment 124326 [details]
2) type something in both text fields (though one should suffice)
3) go to another page or hit back to go to this page
4) hit back (or forward) to go back to the attachment

Result:
the text fields are empty

Expected result:
the text fields (still) have what you typed

To verify nothing funny is going on, try the above with attachment 124325 [details] (just
the frame) and see how the above steps do give the expected result.

Comment 4

[sairuh (rarely reading bugmail)]

this isn't a problem in ns7.02, but turns out it's a regression on the trunk
from over a year ago. looking at commercial linux builds, it worked in
2002.04.08.08 but is broken in 2002.04.18.14.

Comment 5

[Heikki Toivonen (remove -bugzilla when emailing directly)]

John, Radha, any ideas? I think this is pretty major and we should fix this.

Comment 6

[Samir Gehani]

adt: nsbeta1+/adt1

Please add an ETA indicating when this is expected to land on the 1.4 branch. 
Thanks.

Comment 7

[Johnny Stenback (:jst)]

Hmm, this WORKSFORME (todays commercial trunk build, Win2k). Am I missing
something obvious?

Comment 8

[jag (Peter Annema)]

Oddness. Let me find out when (and how) this got fixed.

Comment 9

[Johnny Stenback (:jst)]

Ok, it appears that jag's fix for bug 203960 fixed this on the trunk. Over to
him for possibly fixing this on the branch as well.

Comment 10

[jag (Peter Annema)]

Yep, my patch for 203960 fixed this too.

Comment 11

[jag (Peter Annema)]

Attachment: Correctly save state (forms, scroll position) when a document is being torn down

Comment 12

[jag (Peter Annema)]

Comment on attachment 124850 [details] [diff] [review]
Correctly save state (forms, scroll position) when a document is being torn down

r=jkeiser,adamlock,varga
sr=jst,hewitt

Carried forward from bug 203960.

Comment 13

[Johnny Stenback (:jst)]

From looking at this patch, again, I'd say it's safe to take. Most of the
changes here are moving code around, the real changes are really small, and as
far as I can tell, safe. These changes have been on the trunk for several days
now, and no problems have been reported.

Comment 14

[Asa Dotzler [:asa]]

Do we know what regressed this and whether or not there's a simpler fix?

Comment 15

[John Morrison]

Per jag's request: For builds that I still have around, the testcase
in comment #3 works with a win32 build of 2002-04-11-06-trunk, but
does not work with a (gmake) build of 2002-04-23-08-trunk. So that
narrows the window on the trunk somewhat. Sorry I don't have any more
builds on the trunk during that period of time.

Comment 16

[Asa Dotzler [:asa]]

It's also broken in 0416 builds so that closes the window a bit more.

Comment 17

[Asa Dotzler [:asa]]

oops, ignore me. I was looking at the wrong year. 

Comment 18

[Rafael Ebron (:rebron)]

a=adt.  Please land on branch and add fixed1.4 keyword.

Comment 19

[Asa Dotzler [:asa]]

Comment on attachment 124850 [details] [diff] [review]
Correctly save state (forms, scroll position) when a document is being torn down

a=asa (on behalf of drivers) for checkin to the 1.4 branch.

Comment 20

[jag (Peter Annema)]

Checked in on 1.4branch.

Comment 21

[Prashant Desale]

Verified with 2003-06-16-05-1.4