getElementsByTagName() with uppercase parameter broken

VERIFIED FIXED

Status

()

Core
DOM: Core & HTML
P2
normal
VERIFIED FIXED
17 years ago
9 years ago

People

(Reporter: dannyg, Assigned: jst)

Tracking

({regression})

Trunk
All
Other
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rtm++][HAVE FIX][zarro riisk :-)])

Attachments

(4 attachments)

(Reporter)

Description

17 years ago
I'm filing this as a new bug since my comment in a related bug (56257) hasn't
raised any flags. This is a serious one:

Invoking getElementsByTagName() from any node _other_ than the root #document
node has changed between M17 and M18 to require all lowercase tag name parameters.

Try it on this page. In the Address field enter:

javascript:void alert(document.body.getElementsByTagName("FORM").length)

Result is zip, zero, nada. Now enter:

javascript:void alert(document.body.getElementsByTagName("form").length)

and you get the two forms in this page. Since the Element.tagName property
returns tag names in all uppercase, and since IE and PR2 work with all uppercase
parameters to this method, this needs to be fixed pronto. All of my
developmental XML scripts no longer work in NN6.
(Assignee)

Comment 1

17 years ago
This is indeed a bug in mozilla, however, since you're talking about XML scripts
I get a bit confused. Everything is and should be case sensitive in XML
documents, including XHTML documents, so I don't see how this bug could cause
problems in XML files, especially not in XHTML files where everything is lowercase?

I'll attach a patch that fixes this, and nominating for rtm.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: correctness, regression, rtm
Priority: P3 → P2
(Assignee)

Comment 2

17 years ago
Created attachment 17702 [details] [diff] [review]
Proposed fix
(Reporter)

Comment 3

17 years ago
They're not XML scripts per se, but rather scripts that work with XML elements
embedded within an HTML document. IOW, stuffing some XML from a database into an
HTML document, and then using JavaScript on the client to convert the data into
convenient arrays of objects to facilitate sorting (etc.) to go beyond XSLT.

Thanks for seeing to this one.

Comment 4

17 years ago
r=nisheeth.

Comment 5

17 years ago
Marking rtm need info while jst gets a super review for his fix.
Whiteboard: [rtm need info]
(Assignee)

Comment 6

17 years ago
I just realized (while talking to Vidur about this) that the attached patch
makes it impossible to find upper-case elements within an XHTML element, I'll
attach a new patch that fixes that.
(Assignee)

Comment 7

17 years ago
Created attachment 17916 [details] [diff] [review]
New XHTML safe fix
(Assignee)

Comment 8

17 years ago
Created attachment 17917 [details] [diff] [review]
New XHTML safe fix without some unnecessary cleanup
(Assignee)

Comment 9

17 years ago
Created attachment 17918 [details] [diff] [review]
Final XHTML safe fix, I'm done now, really

Comment 10

17 years ago
r=pollmann.  This is an extremely low risk fix.

Comment 11

17 years ago
sr=vidur. The fix looks pretty good. Since we're going from having strong case
requirements for the tagname parameter to weaker case requirements, I feel
pretty good about this.
(Assignee)

Comment 12

17 years ago
Marking rtm+, hoping to get this marked as a limbo bug...
Whiteboard: [rtm need info] → [rtm+][HAVE FIX][zarro riisk :-)]

Comment 13

17 years ago
Please land this on the trunk asap to get some back time, while we keep this in
limbo for the N 6 branch.
(Assignee)

Comment 14

17 years ago
Thank you, the fix is now checked into the trunk.

Comment 15

17 years ago
This bug is in candidate limbo.  We will reconsider this fix once we have a
candidate in hand, but we can't take this fix before then.

Comment 16

17 years ago
PDT marking [rtm++]. This bug is now out of limbo and approved for checkin to
the branch. Please check in ASAP.

Whiteboard: [rtm+][HAVE FIX][zarro riisk :-)] → [rtm++][HAVE FIX][zarro riisk :-)]
(Assignee)

Comment 17

17 years ago
Fix checked into the branch, marking FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 18

17 years ago
I now get the inverse result ("FORM" yields '2', "form" nada) using the 10-31-14
MN6 candidate build on Win98.  Is that correct? If so, consider verified on one
platform.

Comment 19

17 years ago
using the ns6 build from 2000103114 on Macintosh, I now get 2 for each dialog
(unlike Peter).

Comment 20

17 years ago
I just tried this on NT using the 10-30-14 branch builds and I got 2 for both
"FORM" and "form".  Marking with the vtrunk keyword, so that this bug is also
verified on the trunk.
Keywords: vtrunk

Comment 21

17 years ago
verified: 
2000-11-06-09-MN6 : win32 
2000-11-06-09-MN6 : linux
2000-11-06-08-MN6 : mac 
2000-11-07-08-Mtrunk : linux


Locks up the browser on these trunk builds:
2000-11-07-08-Mtrunk : win32
2000-11-07-08-Mtrunk : mac
 
Component: DOM Level 1 → DOM HTML

Comment 22

17 years ago
QA contact Update
QA Contact: janc → desale

Comment 23

16 years ago
Updating QA contact to Shivakiran Tummala.
QA Contact: desale → stummala

Comment 24

16 years ago
verified 
Status: RESOLVED → VERIFIED

Updated

9 years ago
Component: DOM: HTML → DOM: Core & HTML
QA Contact: stummala → general
You need to log in before you can comment on or make changes to this bug.