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:
Result is zip, zero, nada. Now enter:
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.
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.
Created attachment 17702 [details] [diff] [review]
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
convenient arrays of objects to facilitate sorting (etc.) to go beyond XSLT.
Thanks for seeing to this one.
Marking rtm need info while jst gets a super review for his fix.
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.
Created attachment 17916 [details] [diff] [review]
New XHTML safe fix
Created attachment 17917 [details] [diff] [review]
New XHTML safe fix without some unnecessary cleanup
Created attachment 17918 [details] [diff] [review]
Final XHTML safe fix, I'm done now, really
r=pollmann. This is an extremely low risk fix.
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.
Marking rtm+, hoping to get this marked as a limbo bug...
Please land this on the trunk asap to get some back time, while we keep this in
limbo for the N 6 branch.
Thank you, the fix is now checked into the trunk.
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.
PDT marking [rtm++]. This bug is now out of limbo and approved for checkin to
the branch. Please check in ASAP.
Fix checked into the branch, marking FIXED.
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
using the ns6 build from 2000103114 on Macintosh, I now get 2 for each dialog
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.
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
QA contact Update
Updating QA contact to Shivakiran Tummala.