Closed Bug 57626 Opened 24 years ago Closed 23 years ago

Anchor name pollutes document name space.

Categories

(Core :: Layout, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9

People

(Reporter: bht237, Assigned: jst)

References

Details

(Keywords: testcase)

Attachments

(1 file)

While this is not a big deal to work around, finding such a thing can be a damn
nuisance. Some authors have simple links on their pages that go to "top" which
is in fact quite a logical name :)
You add some JavaScript to such a page und you are stuffed :(

The test case fails with "top.test() is not a function"
<HTML>
<HEAD>
<SCRIPT>
function test(){
}//End test()
</SCRIPT>
</HEAD>
<BODY>
<A NAME="top"></A>
<FORM>
<INPUT type=button value="Test" onClick="top.test()">
</FORM>
</BODY></HTML>
Keywords: 4xp, testcase
over to HTML Element
Assignee: asa → clayton
Status: UNCONFIRMED → NEW
Component: Browser-General → HTML Element
Ever confirmed: true
QA Contact: doronr → lorca
Reporter-
I tried running this testcase on a Mac build 10-24-08 and get no such error.
What date build are you using?
Reply to Dan Lorca: Fails on 2000102004 on Win95. Will download latest and re-test.
Reply 2 to Dan Lorca: Fails on 2000102604 on Win95.
Error displays in JavaScript console.
XML/DOM team's turn to triage Clayton's bugs.
Assignee: clayton → jst
Brendan, is there anything we can do about this? The problem is that 'top' in
the input elements onclick handler resolves to document.top which is the anchor
named 'top' and not to window.top, ideas? Do we need to special case the global
properties in the documents Resolve method, doesn't feel like something I'd
wanna do but is there some other way around this problem?
Status: NEW → ASSIGNED
OS: Windows 95 → All
Hardware: PC → All
jst: no need to try to have your cake and eat it too -- this bug is simply about
a DOM level 0 incompatibility (maybe not with the spec, but certainly with Nav2
thru 4).  The old code,
http://lxr.mozilla.org/classic/source/lib/libmocha/lm_href.c#548, never bound a
named anchor by its NAME attribute's value in document.  It did bind the anchor
by its name and index in document.anchors.  I'm revising the Summary slightly.

/be
Summary: Anchor name pollutes window name space. → Anchor name pollutes document name space.
I agree. As a JavaScript user, I would not expect to find an anchor by 
document.<anchorName>
Ok, my bad. The problem is not that document.top resolves to the anchor element,
the problem is in HTMLFormElement::Resolve(), if the name being resolved in a
form isn't found in the form the Resolve() method calls GetElementsByName() on
the document, and that'll find any element with a 'name' attribute that matches
(per the spec). We'd need to call something other than GetElementsByName() on
the document in nsHTMLFormElement::Resolve()...

Target Milestone: --- → mozilla0.9
Setting target milestone to mozilla0.9, this mess needs some cleaning up
*** Bug 63289 has been marked as a duplicate of this bug. ***
*** Bug 63752 has been marked as a duplicate of this bug. ***
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
qa contact updated.
QA Contact: gerardok → bsharma
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Fix checked in.
Status: RESOLVED → VERIFIED
Verified on:
build: 2001-04-09-11-Mtrunk
Platform: Win 2000

The page loads fine.
SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.
Component: HTML Element → Layout
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: