372887 - On reload of a form with a dynamic input field, form shifts down values

Status: UNCONFIRMED

(Core :: Layout: Form Controls, defect)

Description

[Jacob Davenport]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20070220 Firefox/2.0.0.2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20070220 Firefox/2.0.0.2

When you refresh a form with a dynamically created input element, the static input values that existed before the refresh shift down to the point where the dynamically created element was created.

Reproducible: Always

Steps to Reproduce:
Make a static page with:

<input>Before<br>
<span id="span_id"></span>Dynamic<br>
<input>First<br>
<input>Second<br>
<input>Third<br>
<input>Fourth<br>
<script language="javascript">
document.getElementById('span_id').appendChild(document.createElement('input'));
</script>
<input>Last<br>

Load this up, and there are seven input fields, one of which was created dynamically.  Fill them all in with different values.  Reload the page.
Actual Results:  
When you reload that page, values in Before and Last stay put, but the Dynamic value move to First, the First value moves to Second, Second to Third, Third to Fourth, and Fourth is lost.

Expected Results:  
It is expected that the Dynamic value would be lost and that First, Second, Third, and Fourth would be retained, as Before and Last were.

It seems that the refresh remembers the array of values when the refresh was requested, but then puts them into the input values in the order it finds them went it loads.  Understandable, not critical, but incorrect.

Comment 2

[Martijn Wargers (dead)]

Attachment: testcase from comment 0

On trunk builds, it reacts a little different. Except for the first and last input, any entered text get lost on reload.

Comment 3

[Martijn Wargers (dead)]

Probably the same as bug 140697, marking dependent for now. 

Comment 4

[Aleksei Perepelkin [:chaos]]

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

Still reproducible.

Comment 5

[Jefferson]

Upon reload, Firefox seems to assign attributes of form elements based on numeric position in the form if the elements do not have name attributes. Since this takes place before the script inserts the fields, the results are incorrect. It's easy enough to work around, but a trap for the unwary. Query whether there actually is a solution?

SuMo Thread May 2013: https://support.mozilla.org/en-US/questions/959372

MozillaZine Thread Sept. 2013: http://forums.mozillazine.org/viewtopic.php?f=25&t=2745101

Comment 6

[tm]

As of Firefox 70.0, this is still happening.

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Firefox/70.0

In tests on v70, it does not appear to matter whether name="..." or id="..." attributes are present or missing on the hidden elements. This does not appear to be a viable workaround. Related, I'm seeing Firefox overwrite values from one hidden element to another hidden element, each with distinct values for name="...".

I also tried nesting hidden elements in different div's. The incorrect data repopulation appears to happen even to elements in different locations in the DOM.

Additionally, I tried adding id="<random-value>" to the form element itself to see if that would cause Firefox to refrain from populating values at all, but it doesn't. FF seems to treat forms with unique id's as the same and still repopulates data incorrectly.

I should also note I've seen examples where the incorrect value shifts to a field above the original/proper field and also below.

It would seem that at the least, elements with unique values for attributes like name=, id=, and so on should be uniquely identifiable and thus should not mix up values.

Since we are now in a world where the norm is for modern web apps to make dynamic changes to the DOM, is there any chance this being looked at?

Comment 7

[Emilio Cobos Álvarez (:emilio)]

(In reply to tm from comment #6)
The test-case in comment 2 works for me in current Nightly. And I took a look and it's been working quite a few releases after.

Is there any chance you could provide a test-case that reproduces the issue?