When you set document.mainform.x.name = "y"; and then do
alert(document.mainform.x.name); it will show up as "y". This means we can
still access the element by its old name.
In the URL, click "name", "(set)", and then "name" again on any of the selects.
The fact that the "name" succeeds illustrated the problem.
Created attachment 49884 [details] [diff] [review]
The fix for this is to simply not define form.foo when 'foo' is resolved on the
form, doing that didn't really give us anything since we do the real work in
::GetProperty() in the helper.
Hmm, never mind, the attached patch isn't quite right.
Created attachment 50331 [details]
Created attachment 50332 [details]
testcase minor correction
Created attachment 50359 [details] [diff] [review]
jband, brendan, r/sr=?
before checking in the patch (which looks good), would it be possible to fix the
large comment so that the first sentence is easier to understand (is there a
missing word?) and also the typo fomr->form.
"the form objects prototype chain" needs an apostrophe in "objects".
The MozillaClassic DOM level 0 code took no steps to remove the old name. Does
IE? Just curious.
Is there an alternative where you remove the old name in the setter for the name
property? Might that be simpler (no anti-recursion required)?
Created attachment 53689 [details] [diff] [review]
Same as above, but should work on AIX too.
Eh, hmm, ignore the above, wrong bug...
Brendan, looks like IE has the same bug. I'm actually not that worried about
formcontrols being reachable by their old name, but the fact that the old name
will shadow a new form control that is inserted with the old name is
unfortunate. Interestingly enough, IE has the same problem. Given that, I'll
move this to mozilla1.0 and we'll decide what to do later on...
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1
(you can query for this string to delete spam or retrieve the list of bugs I've
Looks like browsers interoperably do this, and the spec requires it. See the past names map.