Closed Bug 728798 Opened 12 years ago Closed 11 years ago

Session history for <input> value doesn't work with @form

Categories

(Core :: Layout: Form Controls, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: hectorz, Assigned: almasry.mina)

References

Details

(Keywords: student-project, Whiteboard: DUPEME[mentor=mounir][lang=C++])

Attachments

(1 file, 1 obsolete file)

Attached file contains bugtest.html and bugtest.xpi (obsolete) —
See attached test case.

In the html page, an input element is linked to its owner form using the form attribute, not as a descendant. The test extension simply registers an unload event handler for the every page opened.

Fill in some text and submit. Hit the back button, and there's nothing in the input field.
If that's a DOM issue, why do you need an extension to reproduce it?
(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #1)
> If that's a DOM issue, why do you need an extension to reproduce it?

You're right.

The bug was found in an extension, so we tried to reduce the extension without realizing that we don't need one. Test case updated. Thanks!
Attachment #598780 - Attachment is obsolete: true
Component: HTML: Form Submission → Form Manager
Product: Core → Toolkit
QA Contact: form-submission → form.manager
Version: unspecified → Trunk
Summary: Session history form autocompletion broken by unload event handler → Session history form autocompletion doesn't work with @form
Component: Form Manager → Layout: Form Controls
Product: Toolkit → Core
QA Contact: form.manager → layout.form-controls
Summary: Session history form autocompletion doesn't work with @form → Session history for <input> value doesn't work with @form
nsContentUtils::GenerateStateKey includes the index of the input in its form's controls in the key, if the input has a form.  That means that when _saving_ state on page unload we include the index in the key, since the input has a form at that point.  But when _restoring_ state we do that when the input is parsed, which is before the form is parsed, so it has no form at that point, and we end up with a different key.  And then we can't find the value.

There are existing bugs which cover the fact that we should be generating the save and restore keys at the same time in the page's life...  We really need to find someone with the time to fix that.  :(
Whiteboard: DUPEME
I guess the other option for this bug is to not look at the form if it's linked to via @form...
I guess we could get students working on that.
Keywords: student-project
Whiteboard: DUPEME → DUPEME[mentor=mounir][lang=C++]
Depends on: 737851
Do you have to be a student to do this? I'd like to take this too, especially if I can work on bug 737851 as well.
(In reply to Mina Almasry from comment #6)
> Do you have to be a student to do this? I'd like to take this too,
> especially if I can work on bug 737851 as well.

No, it's just a bigger bug so it could work as project but there is no requirement about being a student.
Assignee: nobody → almasry.mina
The "Updated test case, html only" WFM. Can we verify is this is still an issue? This might have been fixed in bug 737851
(In reply to Mina Almasry [:mina] from comment #8)
> The "Updated test case, html only" WFM. Can we verify is this is still an
> issue? This might have been fixed in bug 737851

The test case works as expected for me in Fx 26, I guess this is fixed.

Should I resolve this bug as FIXED or WFM?
-> WORKSFORME
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: