267552 - Accessing form element from script works using id but not name unless it is fully qualified

Status: RESOLVED INVALID

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

Description

[Nuno Boavida]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1

This happens since Mozilla 1.7 and both in Windows and Linux.

A field in a form has a name but not id. An event in another element tries to
write to the field. It works if the name is qualified:
document.form1.somefield.value = 'foo'
but not otherwise:
somefield.value = 'foo'
If the field has an id, this works ok. The HTML4.0.1 spec says an element may be
accessed both by name or id, and says both are unique in the document. Why the
difference in behaviors, here?

An event is executed in the context of the object that generates it. The
ECMAScript spec says that a name is evaluated in relation to the context, or in
the global context. Then, the code in the event shouldn't be able to access an
object through its unqualified name because the object is child of form, and the
event code executes in the context of its sibling, not the form. But it used to
work. Now, it doesn't work anymore, but only for name, not for id.


Reproducible: Always
Steps to Reproduce:
1. Open the attached HTML in IE or Mozilla 1.6. Everything works.
2. Open the attached HTML in Mozilla >= 1.7 or Firefox 1. The "not working"
anchor doesn't work.
3. Change the string name="somefield" to id="somefield". Now it works in Firefox.

Actual Results:  
In IE or Mozilla 1.6 :
Clicking on the "working" anchor writes "working" in the field above. Clicking
on "not working" anchor writes "not working" in the field above.

In Mozilla > 1.7 or Firefox 1:
Clicking on the "working" anchor writes "working" in the field above. Clicking
on "not working" does nothing. The javascript debugger shows "somefield is not
defined".

AFTER CHANGING THE FIELD'S NAME FIELD TO ID:
In IE or Mozilla 1.6 :
Clicking on the "working" anchor writes "working" in the field above. Clicking
on "not working" anchor writes "not working" in the field above, but the
Javascript console shows: "Warning: Element referenced by ID/NAME in the global
scope. Use W3C standard document.getElementById() instead."


Expected Results:  
The behavior should be consistent using either name or id.

Comment 1

[Nuno Boavida]

Attachment: HTML testcase

Comment 2

[Boris Zbarsky [:bzbarsky]]

jst, this broke when we removed the scope-chain crawl....

The problem, of course, is that ID is required to be unique, while name is not.
 I don't know where reporter got the idea that a name is unique in the document,
since it's clearly stated in the spec that this is NOT the case.  So extending
the ID lookup in global scope that we do to name would sometimes produce rather
odd results...

Comment 3

[Boris Zbarsky [:bzbarsky]]

Actually, reopening.  This _is_ a regression, this works in IE, and we need to
decide for ourselves when we should or should not do name lookups.

Comment 4

[Brendan Eich [:brendan]]

This is a gross IE quirk, so the reporter should note that citing HTML4.0.1
doesn't help.  But we're in for a penny, in for a pound.  Jst, what do you say?

/be

Comment 5

[Johnny Stenback (:jst)]

We've seen this in a few bugs already, and it may be worth doing, but I don't
know for sure yet. Bob Clary might have thoughts here. Cc:ing.

Comment 6

[Bob Clary [:bc] (inactive)]

Attachment: Modified testcase with buttons

Add buttons with fully qualified and name qualified accesses.

The name lookup works in the button |click| handler in Mozilla but not the |a|
handler. The global reference somefield fails in both Mozilla and MSIE6 both
inside and outside the form.

I never did like this scope crawl thing, but if we do it for button handlers
why not others?

Comment 7

[Nuno Boavida]

(In reply to comment #4)
> This is a gross IE quirk, so the reporter should note that citing HTML4.0.1
> doesn't help.  But we're in for a penny, in for a pound.  Jst, what do you say?
> 
> /be

Take it easy, I misunderstood the spec before, or else I wouldn't have created
this bug entry. Now I read it more carefully, and I absolutely agree with you
this is a gross IE quirk.

Comment 8

[Brendan Eich [:brendan]]

Nuno, I always take it easy ;-).  If there was a trace of pique in my attitude,
it was because we already have emulated gross IE quirks, in order to avoid
roadblocks to distribution and greater market share.  That precedent was what I
was referring to by "in for a penny, in for a pound."  So we should probably
emulate this name lookup stuff, too, in quirks mode docs.

Bob, does the quirks correlation hold up here too?

/be

Comment 9

[Bob Clary [:bc] (inactive)]

I don't have any data on this, but I would think that this would be both quirks
and standards mode particularly as the same behavior is seen in button handlers...

Comment 10

[HARUNAGA Hirotoshi]

*** Bug 271629 has been marked as a duplicate of this bug. ***

Comment 11

[Boris Zbarsky [:bzbarsky]]

We have at least 3 bugs on this at this point... Would be nice to have the
others depend on this one or something so we can track them all.

Comment 12

[Chris Beard]

Hard to understand what the real impact is here.  Is there anyway we could
measure how much of the web we're actually breaking?  Do we really want to
emulate this quirk? ("In for a penny, in for a pound")

bclary, do you have a feel how much we're breaking?

/cb

Comment 13

[Bob Clary [:bc] (inactive)]

(In reply to comment #12)

> bclary, do you have a feel how much we're breaking?

The tests I have run on the public web don't attempt to click on links or submit
forms etc, so I wouldn't see many of these errors. Tech Evangelism is a good
source to mine for other instances. In a quick search I found a couple more
sites with similar problems.

As for the scope, it is probably a significant amount but is probably decreasing
due to increased Firefox market share. If you think it is worth the time, I can
try to mine the TE bugs more to get a better picture.

Comment 14

[Asa Dotzler [:asa]]

This is more of a nice to have than a blocker. If we get extra cycles from our
"clone JST" efforts, then maybe. otherwise not a blocker.

Comment 15

[Brendan Eich [:brendan]]

No need to clone jst if peterv or sicking can help.

/be

Comment 16

[Ioana (away)]

Removing keyword since Martin already solved the request. I didn't find any other bugs.

I tried the attached testcases and they still don't work on Firefox, but do work on Chrome. Is this something we still want implemented? (given it has not been done for a very long while and nothing that bad happened)

Comment 17

[Boris Zbarsky [:bzbarsky]]

Per current spec this should not work, I believe.  Given the lack of a web-compat reason to change the spec, invalid.

I filed https://code.google.com/p/chromium/issues/detail?id=324828 on Chrome just being buggy here.