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)
Core
Layout: Form Controls
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)
413 bytes,
text/html
|
Details |
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.
Comment 1•12 years ago
|
||
If that's a DOM issue, why do you need an extension to reproduce it?
Reporter | ||
Comment 2•12 years ago
|
||
(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
Updated•12 years ago
|
Component: HTML: Form Submission → Form Manager
Product: Core → Toolkit
QA Contact: form-submission → form.manager
Version: unspecified → Trunk
Updated•12 years ago
|
Summary: Session history form autocompletion broken by unload event handler → Session history form autocompletion doesn't work with @form
Updated•12 years ago
|
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
Comment 3•12 years ago
|
||
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
Comment 4•12 years ago
|
||
I guess the other option for this bug is to not look at the form if it's linked to via @form...
Comment 5•12 years ago
|
||
I guess we could get students working on that.
Keywords: student-project
Whiteboard: DUPEME → DUPEME[mentor=mounir][lang=C++]
Assignee | ||
Comment 6•11 years ago
|
||
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.
Comment 7•11 years ago
|
||
(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 | ||
Updated•11 years ago
|
Assignee: nobody → almasry.mina
Assignee | ||
Comment 8•11 years ago
|
||
The "Updated test case, html only" WFM. Can we verify is this is still an issue? This might have been fixed in bug 737851
Reporter | ||
Comment 9•11 years ago
|
||
(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?
Comment 10•11 years ago
|
||
-> 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.
Description
•