Last Comment Bug 14869 - getElementsByTagName() returns HTMLCollection instead of NodeList
: getElementsByTagName() returns HTMLCollection instead of NodeList
Status: RESOLVED WONTFIX
: helpwanted
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: -- normal with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Andrew Overholt [:overholt]
Mentors:
: 312427 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 1999-09-24 14:29 PDT by ckritzer (gone)
Modified: 2013-04-04 08:13 PDT (History)
19 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase from comment 16 (461 bytes, text/html)
2010-01-01 22:13 PST, Jesse Ruderman
no flags Details
getElementsBy* dont' return NodeList (1.41 KB, text/plain)
2011-05-24 03:18 PDT, unbugger
no flags Details
Broken patch (5.52 KB, patch)
2012-01-17 15:29 PST, Corey Richardson (:cmr)
no flags Details | Diff | Splinter Review
Working patch -- getElementsBy*() returns a NodeList (6.74 KB, patch)
2012-01-17 19:20 PST, Corey Richardson (:cmr)
no flags Details | Diff | Splinter Review

Description ckritzer (gone) 1999-09-24 14:29:52 PDT
Overview Description: the getElementsByTagName() function is returning an
HTMLCollection instead of a NodeList.  According to the spec, it should be
returning a NodeList.

Steps to Reproduce:
1) Load the following html into the browser:
*****************************************************************************

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<HTML>
	<HEAD>
		<TITLE>test.html</TITLE>
	</HEAD>
	<BODY>
		<SCRIPT type="text/javascript">
			document.write("<p>");
			document.write("<b>childNodes</b> should return a <b>NodeList</b><br>");
			document.write("<b>Expected Results:</b> document.firstChild.childNodes =
[object NodeList]<br>");
			document.write("<b>Actual Results:</b> document.firstChild.childNodes = " +
document.firstChild.childNodes + "<br>");
			document.write("<hr>");
			document.write("<b>getElementsByTagName</b> should return a
<b>NodeList</b><br>");
			document.write("<b>Expected Results:</b>
document.firstChild.getElementsByTagName('*') = [object NodeList]<br>");
			document.write("<b>Actual Results:</b>
document.firstChild.getElementsByTagName('*') = " +
document.firstChild.getElementsByTagName('*') + "<br>");
		</SCRIPT>
	</BODY>
</HTML>


*****************************************************************************
2) Read the printout


Actual Results: [object HTMLCollection]


Expected Results: [object NodeList]


Build Date & Platform Bug Found:
1999092408MacOS86
1999092408Win98
1999092408Linux6

Additional Builds and Platforms Tested On:


Additional Information:
Comment 1 vidur (gone) 1999-10-14 17:53:59 PDT
This does the right thing in the C++ interface. The methods of NodeList are a
subset of the methods of HTMLCollection, so the script user shouldn't see any
difference. Marking WONTFIX for this release.
Comment 2 ckritzer (gone) 1999-10-27 10:31:59 PDT
Marking VERIFED WONTFIX for this release per vidur's comments.
Comment 3 Sjoerd Visscher 2005-07-12 13:02:09 PDT
Well, Vidur was wrong. I noticed today. :)

If I add a method to the NodeList prototype, I should be able to call that
method on the result of getElementsByTagName:

NodeList.prototype.test = function() { alert("test"); }
document.getElementsByTagName('*').test();

This works in Opera.
Comment 4 Pratik 2005-07-16 00:55:42 PDT
This bug is fixed. Here's the results I get with a recent firefox nightly (20050622)

childNodes should return a NodeList
Expected Results: document.firstChild.childNodes = [object NodeList]
Actual Results: document.firstChild.childNodes = [object NodeList]
getElementsByTagName should return a NodeList
Expected Results: document.firstChild.getElementsByTagName('*') = [object NodeList]
Comment 5 Peter Van der Beken [:peterv] 2005-07-16 04:30:33 PDT
This is not fixed. getElementsByTagName still returns [object HTMLCollection].
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2005-07-18 08:36:26 PDT
See bug 162927 and bug 143191.
Comment 7 Sjoerd Visscher 2005-07-18 09:22:41 PDT
Ah, yes, the getElementsByTagName result does indeed return true when doing
instanceof NodeList. 

Then adding methods to NodeList.prototype should work right? Maybe my only
problem is bug 300519.
Comment 8 Boris Zbarsky [:bz] (still a bit busy) 2006-04-19 09:59:24 PDT
*** Bug 312427 has been marked as a duplicate of this bug. ***
Comment 9 Jesse Ruderman 2007-02-26 02:13:19 PST
How does this differ from bug 162927?  The summaries are almost identical.
Comment 10 Miguel 2007-06-15 13:11:36 PDT
I have this problem using prtototype.js framework

...
<tr id="tr_1">
<form id="frm_1" name="frm_1">
  <input type="hidden" value="x" id="x" name="x">
  <td>  <input type="text" id="y" name="x"></td>
  <td>  <input type="text" id="z" name="z"></td>
</form>
</tr>
<tr id="tr_2">
<form id="frm_2" name="frm_2">
  <input type="hidden" value="x" id="x" name="x">
  <td>  <input type="text" id="y" name="x"></td>
  <td>  <input type="text" id="z" name="z"></td>
</form>
</tr>
<tr id="tr_3">
<form id="frm_3" name="frm_3">
  <input type="hidden" value="x" id="x" name="x">
  <td>  <input type="text" id="y" name="x"></td>
  <td>  <input type="text" id="z" name="z"></td>
</form>
</tr>
...

(Removed not important code from original.)

I use this javascript:


modify = function(id){
//id is a number
...
  var myform = $('frm_' + id);
  var param = myfrom.serialize();
...
}

The problems:
- myform return HTMLCollention instead nodeList
- param return nothing

Cheking prootype.js look what use getElementsbyTagName('*') for collect elements .
I have another code what work fine, the only diference is what i have ONE form

I use Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0


Comment 11 Miguel 2007-06-21 10:28:27 PDT
Well, i found the bug in my code

i have before:
...
<tr id="tr_1">
<form id="frm_1" name="frm_1">
  <input type="hidden" value="x" id="x" name="x">
  <td>  <input type="text" id="y" name="x"></td>
  <td>  <input type="text" id="z" name="z"></td>
</form>
</tr>
<tr id="tr_2">
<form id="frm_2" name="frm_2">
  <input type="hidden" value="x" id="x" name="x">
  <td>  <input type="text" id="y" name="x"></td>
  <td>  <input type="text" id="z" name="z"></td>
</form>
</tr>
<tr id="tr_3">
<form id="frm_3" name="frm_3">
  <input type="hidden" value="x" id="x" name="x">
  <td>  <input type="text" id="y" name="x"></td>
  <td>  <input type="text" id="z" name="z"></td>
</form>
</tr>
...

Checking with DOM Inspector the tree see that:
HTML
  BODY
    DIV
      TABLE
        form
        tr
          td
            input
          td
            input
          td
            input
        form
        tr
          td
            input
          td
            input
          td
            input
...

How can you see , the form element NOT have childrens, so i change code (only posted in DOM Tree):
html
  body
    div
      table
        tr
          td
            form
              table
                tr
                  td
                    input
                  td
                    input
                  td
                    input
        tr
          td
            form
              table
                tr
                  td
                    input
                  td
                    input
                  td
                    input
...

This way myform.getElementaByTagName('*') return HTMLCollention (thats is correct, i know now) and "var param = myfrom.serialize();" return form fields

Maybe this is not bug from DOM, only a bad page desing
Comment 12 Jesse Ruderman 2007-06-21 13:09:47 PDT
The last two comments sound like bug 265976.  Do they have anything to do with this bug?
Comment 13 polonus 2007-06-23 17:50:21 PDT
GetElementsByTagName or GetElementsByClassName etc. slows FF down considerably, to have a more flexible working and faster (page) loading save the following file as SelectableElementsTable.js inside the components folder of your browser.
The download link for my javascript file is here:
http://www.4shared.com/file/18447141/4fd08f46/SelectableElementsTable.html
File size: 10835 bytes
MD5: 405c4b524f49c958c285bff1c58944c3
SHA1: c2cc25768d16a02d4db8b02e12cab4ae5dec5085

I got various reports that attest that the script makes the browser load pages considerably faster. But I like to get back info from you if this could be brought in. Somebody take to test this?
Comment 14 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-06-24 06:14:37 PDT
Polonus, could you file a new bug on that and attach the javascript file to the bug? Thanks.
Comment 15 Gérard Talbot 2008-01-29 18:40:52 PST
Hello all,

Is this bug still occuring, happening... or should it be resolved as a DUPLICATE of bug 162927 ? 

Thank you, Gérard
Comment 16 David Bruant 2009-12-31 09:25:28 PST
I confirm it is still occuring on FF 3.5. I've written another test : 
*********************************************************
<!DOCTYPE html>
<html>
  <head>
    <title>document.getElementsByTagName misbehavior</title>
  </head>
  
  <body>
     <script type="text/javascript">
          document.write("Object.prototype.toString.call(document.getElementsByTagName('*')) : ");
          document.write("<b>" + Object.prototype.toString.call(document.getElementsByTagName('*')) + "</b>");
          document.write("<br>(<b>[object NodeList]</b> expected)");
     </script>
  </body>
</html>
*********************************************************
Comment 17 Jesse Ruderman 2010-01-01 22:13:29 PST
Created attachment 419774 [details]
testcase from comment 16
Comment 18 Boris Zbarsky [:bz] (still a bit busy) 2010-01-02 08:43:11 PST
The test in comment 16 is just looking at what toString returns.  That's not that important (and in particular the spec does NOT define what toString should be).  The real question is whether instanceof NodeList tests true (it used to, but doesn't seem to anymore; someone should figure out when that stopped working) and whether extending NodeList.prototype makes things show up on the object (but this is generally broken in Gecko).
Comment 19 unbugger 2011-05-24 03:18:15 PDT
Created attachment 534703 [details]
getElementsBy* dont' return NodeList
Comment 20 Corey Richardson (:cmr) 2012-01-16 08:29:15 PST
It's still happening, Firefox 12 nightly.. I'm determined to fix this. My test case will be http://jsfiddle.net/DRRcX/8/.
Comment 21 David Bruant 2012-01-16 09:29:36 PST
(In reply to Corey Richardson from comment #20)
> It's still happening, Firefox 12 nightly.. I'm determined to fix this. My
> test case will be http://jsfiddle.net/DRRcX/8/.
It's likely to be enough, but why not using the test cases attached above?
Anyway, good luck, I'm looking forward to seeing this one fixed :-)
Comment 22 Corey Richardson (:cmr) 2012-01-17 04:24:14 PST
Good progress made, I think I have a fix, now just to build and test :)
Comment 23 Corey Richardson (:cmr) 2012-01-17 15:29:29 PST
Created attachment 589323 [details] [diff] [review]
Broken patch

This patch does NOT work! It is simply here for posterity (and ease of reference). Tried to implement some advice from bz, didn't go too well.
Comment 24 Josh Matthews [:jdm] (on vacation until Dec 5) 2012-01-17 15:42:32 PST
You forgot to set mExposed in nsContentList::nsContentList. See if that helps!
Comment 25 Corey Richardson (:cmr) 2012-01-17 19:20:25 PST
Created attachment 589392 [details] [diff] [review]
Working patch -- getElementsBy*() returns a NodeList

Thanks for catching that, a silly oversight. It should work now, my own testcase I can't confirm because, well, tip won't run jsfiddle. I used the test case from 16 instead. What's next?
Comment 26 Boris Zbarsky [:bz] (still a bit busy) 2012-01-17 19:27:06 PST
Some combination of asking for review and running the test suite.  I can push the patch to try for you if you like.

But again, I suspect that not having namedItem on these lists will be a compat problem....
Comment 27 Corey Richardson (:cmr) 2012-01-17 19:48:48 PST
The |make check| passed, but there were 14 failures for |make xpcshell-test|. Currently building a clean source tree to see if my patch affected that number. I really hope no sites depend on behaviour that shouldn't exist... I am using tip of mozilla-beta, btw.
Comment 28 Boris Zbarsky [:bz] (still a bit busy) 2012-01-17 20:40:35 PST
> The |make check| passed, but there were 14 failures for |make xpcshell-test|.

You'll also need to run mochitest (regular, chrome, browser-chrome) and reftest.... It's easier to just push to try once you have a patch you're happy with.

> I really hope no sites depend on behaviour that shouldn't exist...

Sites depend on things like that all the time.  I'll be extremely shocked if the patch as-is doesn't break some sites.
Comment 29 Corey Richardson (:cmr) 2012-01-17 22:12:00 PST
(In reply to Boris Zbarsky (:bz) from comment #28)
> > The |make check| passed, but there were 14 failures for |make xpcshell-test|.
> 
> You'll also need to run mochitest (regular, chrome, browser-chrome) and
> reftest.... It's easier to just push to try once you have a patch you're
> happy with.
> 

Please and thank you :)

> > I really hope no sites depend on behaviour that shouldn't exist...
> 
> Sites depend on things like that all the time.  I'll be extremely shocked if
> the patch as-is doesn't break some sites.

Sure. But the MDN says it returns a NodeList. The spec says it returns a
NodeList. When you don't follow the spec, how can you expect breakages not to
occur? How can we claim to render in standards mode with inconsistencies like
this... not saying the spec is perfect, but it should at least be followed. Maybe that's just me, though :\
Comment 30 Corey Richardson (:cmr) 2012-01-17 22:21:56 PST
Chrome (and presumably all webkit) and Opera have the correct behavior. It's just FF and IE that do it wrong.
Comment 31 Boris Zbarsky [:bz] (still a bit busy) 2012-01-17 22:55:55 PST
> how can you expect breakages not to occur?

Authors don't read the spec.  Or MDN, mostly.  They just copy/paste whatever works.

> not saying the spec is perfect, but it should at least be followed.

Or, in this case, changed, because there's no good reason for it to be the way it is other than internal W3C politics from 10 years ago.  See http://lists.w3.org/Archives/Public/www-dom/2012JanMar/0007.html

> and Opera

Opera has a non-spec namedItem method on all NodeLists.  It's only WebKit that doesn't have a namedItem on the return value of getElementsByTagName.  I wouldn't mind the change if we had a namedItem on NodeList, but of course then you have to implement it on stuff like childNodes and so forth... and it's still not following the current spec.

I pushed the patch to try.  https://tbpl.mozilla.org/?tree=Try&rev=122abba4c7f2
Comment 32 Corey Richardson (:cmr) 2012-01-17 23:16:17 PST
(In reply to Boris Zbarsky (:bz) from comment #31)
> > how can you expect breakages not to occur?
> 
> Authors don't read the spec.  Or MDN, mostly.  They just copy/paste whatever
> works.
> 

Sad that that's what it has come to. 

> > not saying the spec is perfect, but it should at least be followed.
> 
> Or, in this case, changed, because there's no good reason for it to be the
> way it is other than internal W3C politics from 10 years ago.  See
> http://lists.w3.org/Archives/Public/www-dom/2012JanMar/0007.html
> 

Changing the spec is even better if the spec no longer makes sense. Do you think the change is likely?

> > and Opera
> 
> Opera has a non-spec namedItem method on all NodeLists. 

Fair enough.

Changing the spec does make the most sense to me, I still can't really figure out why NodeList and HTMLCollection both exist. 

In any case, this has served as a good ice breaker, I think I might get more involved in the project somehow.
Comment 33 Boris Zbarsky [:bz] (still a bit busy) 2012-01-17 23:23:50 PST
> Sad that that's what it has come to. 

That's how HTML has pretty much always worked.  That's why it was successful.  ;)

> Do you think the change is likely?

I don't know.

> I still can't really figure out why NodeList and HTMLCollection both exist. 

Because HTMLCollection was defined in the "DOM HTML" specification but there were methods in the "DOM Core" specification that wanted to return nodelists.... but couldn't return HTMLCollection, because it was in a different specification.

Like I said, politics.  From 10 years ago.
Comment 34 David Bruant 2012-01-18 01:20:25 PST
(In reply to Boris Zbarsky (:bz) from comment #31)
> (...)
> It's only WebKit
> that doesn't have a namedItem on the return value of getElementsByTagName.
If it's the case since the beginning of Webkit, then it means that no compatibility issues have been found since the introduction of Safari and Chrome in the market (otherwise, they would have added the namedItem method).

I think I recently saw a study of which property names were used in on* attributes (was it by you?). If there is such a tool around, could it be run to see whether "namedItem" is actually used on the web.
Comment 35 :Ms2ger (⌚ UTC+1/+2) 2012-01-18 03:28:17 PST
https://tbpl.mozilla.org/?tree=Try&rev=122abba4c7f2

Something doesn't look happy here.

(In reply to David Bruant from comment #34)
> I think I recently saw a study of which property names were used in on*
> attributes (was it by you?). If there is such a tool around, could it be run
> to see whether "namedItem" is actually used on the web.

Note that this also affects list.foo and list["foo"], which are rather harder to look for.
Comment 36 David Bruant 2012-01-18 03:51:31 PST
(In reply to Ms2ger from comment #35)
> (In reply to David Bruant from comment #34)
> > I think I recently saw a study of which property names were used in on*
> > attributes (was it by you?). If there is such a tool around, could it be run
> > to see whether "namedItem" is actually used on the web.
> 
> Note that this also affects list.foo and list["foo"], which are rather
> harder to look for.
oh ok. I didn't know that. It indeed makes things much harder.
Comment 37 Mozilla RelEng Bot 2012-01-18 04:17:01 PST
Try run for 122abba4c7f2 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=122abba4c7f2
Results (out of 215 total builds):
    exception: 6
    success: 21
    warnings: 175
    failure: 13
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bzbarsky@mozilla.com-122abba4c7f2
Comment 38 Corey Richardson (:cmr) 2012-01-18 05:05:39 PST
https://tbpl.mozilla.org/?tree=Try&rev=122abba4c7f2

Anyone else get a "Loading failed: error"?
Comment 39 Boris Zbarsky [:bz] (still a bit busy) 2012-01-18 08:39:09 PST
> then it means that no compatibility issues have been found since the introduction of
> Safari and Chrome in the market

Depending on browser-sniffing that's even possible.

> could it be run to see whether "namedItem" is actually used on the web.

namedItem is used all over the place on the web.  Unlike the on* analysis, which was simple syntax, for purposes of this bug one would have to figure out what sort of object |x| is given the JS "x.namedItem('foo')".  Specifically whether x is document.forms or document.all or something (which have a namedItem per spec) or a document.getElementsByTagName() (which does not).

I just looked through some Google code search results for namedItem, btw, and I see this pattern pop up a few times:

  (document.all || document.getElementsByTagName("*")).namedItem(something)

This works in all non-WebKit browsers; fails in WebKit.

Ms2ger, good point about name lookups!  I hadn't even thought about those.  A simple test shows that both WebKit and Opera support them on the return value of getElementsByTagName.  Of course so do IE and Gecko.  So I expect that's required for web compat.  I'll be posting to the DOM mailing list about this; the spec needs to change.

I don't think it's worth worrying about this bug until the spec is fixed, because the changes we need to make strongly depend on how the spec gets fixed.

> Anyone else get a "Loading failed: error"?

Works ok for me....
Comment 40 Boris Zbarsky [:bz] (still a bit busy) 2012-01-18 08:40:38 PST
Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=15609 in case people are interested.
Comment 41 Marek Stępień [:marcoos, inactive] 2012-01-20 10:33:19 PST
I've added a note describing the various types returned by this method in different browsers to the MDN article at https://developer.mozilla.org/en/DOM/element.getElementsByTagName
Comment 42 Corey Richardson (:cmr) 2012-01-20 12:17:08 PST
When MDN is less broken I'll add notes to https://developer.mozilla.org/en/DOM/document.getElementsByClassName and the rest of 'em.
Comment 43 Marek Stępień [:marcoos, inactive] 2012-01-20 14:59:56 PST
I already did that. MDN has issues with displaying articles currently (mostly code samples), but editing works OK.
Comment 44 unbugger 2012-03-06 01:08:18 PST
Why getElementsBy* can't return a NodeList and,  when all nodes are HtmlElement, return a NodeList which is also an HtmlCollection ?
This should match both DOM and HTML DOM specs and the usual practices on web.
Comment 45 Boris Zbarsky [:bz] (still a bit busy) 2012-03-06 08:24:35 PST
"is" in what sense?

The object returned in fact implements both the NodeList and HTMLCollection interfaces.

It obviously can't inherit from both prototypes, since that's not how prototypes work in JavaScript.
Comment 46 unbugger 2012-03-06 08:41:29 PST
Sorry, bad writing.

In sens that NodeList could inherit HtmlCollection (when all his Node are HtmlElement, of course).
Comment 47 Boris Zbarsky [:bz] (still a bit busy) 2012-03-06 08:43:41 PST
There is no multiple inheritance in JavaScript.
Comment 48 unbugger 2012-03-06 10:34:41 PST
Where is the multiple inheritance ?
Object inherits NodeList inherits HtmlCollection. There is only one inheritance for each prototype.
Comment 49 Boris Zbarsky [:bz] (still a bit busy) 2012-03-06 10:41:22 PST
> Object inherits NodeList inherits HtmlCollection

But NodeList doesn't inherit from HTMLCollection; that's the point.
Comment 50 unbugger 2012-03-06 12:10:32 PST
I missed something... NodeList doesn't inherit another prototype ? So why it's not possible for NodeList to inherit the HTMLCollection prototype ?
Comment 51 Boris Zbarsky [:bz] (still a bit busy) 2012-03-06 12:14:18 PST
The spec defines that NodeList.prototype has Object.prototype as its prototype.
Comment 52 unbugger 2012-03-06 12:29:53 PST
Ah... ok, i expected a slightly more technical reason...
I guess it's also true for HTMLCollection ?
Comment 53 Boris Zbarsky [:bz] (still a bit busy) 2012-03-06 12:33:10 PST
> i expected a slightly more technical reason

Like what?  The fact that HTMLCollection has methods that make no sense on a NodeList?
Comment 54 unbugger 2012-03-07 01:13:51 PST
Anything else, but not the spec breaks the inheritance of NodeList and HTMLCollection.

Come to think twice, the spec is for javascript, not for the browser that prepare objects to be exposed. So the browser should not be concerned by the specification and should be able to make inheritance ?
Comment 55 Boris Zbarsky [:bz] (still a bit busy) 2012-03-07 07:29:08 PST
The spec is for what the prototype chain looks like.  How about you actually read the spec involved?  It's a combination of http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html and http://dev.w3.org/2006/webapi/WebIDL/

In any case, the DOM spec editor recently explicitly made getElementsByTagName return HTMLCollection, basically for the reasons listed in comment 39.  Marking wontfix, since we're doing what the spec calls for at this point...
Comment 57 Boris Zbarsky [:bz] (still a bit busy) 2012-10-06 09:20:25 PDT
I did that, but ... it's a wiki.  What prevented you from updating it yourself?
Comment 58 :aceman 2012-10-06 09:32:41 PDT
I don't feel authoritative enough to change such an important page / doc as I do not have the needed knowledge.
Comment 59 David Bruant 2012-10-06 09:51:27 PDT
(In reply to :aceman from comment #56)
> Can you update
> https://developer.mozilla.org/en-US/docs/DOM/element.getElementsByTagName ?
What change do you wish to see made?
I assume you have an answer, otherwise, you wouldn't be asking ;-)

(In reply to :aceman from comment #58)
> I don't feel authoritative enough to change such an important page / doc as
> I do not have the needed knowledge.
As the DOM topic driver https://developer.mozilla.org/en-US/docs/Project:Topic_drivers (self-proclaimed a minute ago to be fully honest), I grant you the authority to do this change since I assumed above you know which change you want to be seen.

To detail a little more, the doc team really really is understaffed. I'm, myself, just a volunteer contributing on my free time. Be sure of one thing. No one in the doc team will *ever* come at you to say "you don't have the authority, you shouldn't touch that page!". We will largely prefer someone writing content that is half-right and fix it later if needed.
So, I was joking above about "granting" you anything :-) You already have the authority.

For the time being, I encourage you to fix the element.getElementsByTagName page and send me and e-mail or tweet to ask for a review when you feel you're done.
Comment 60 :aceman 2012-10-06 10:08:05 PDT
Thanks, but bz already made the needed change.

Actually I wouldn't do the change even with permission, because I don't know what exactly needs to be done. I just see that it mentions NodeList and bz says it is no longer the case. But apart from that there may have been other side-facts which I would not be knowledgeable enough to add.
Comment 61 David Bruant 2012-10-06 10:14:49 PDT
(In reply to :aceman from comment #60)
> Actually I wouldn't do the change even with permission
You don't need any ;-)

> because I don't know
> what exactly needs to be done. I just see that it mentions NodeList and bz
> says it is no longer the case. But apart from that there may have been other
> side-facts which I would not be knowledgeable enough to add.
It happens to me a lot. I change the doc to the best of my knowledge and then comment on the relevant bug to say it's been documented and limitations/questions I came across and how I solved them.
If people disagree or want to complete, either they ask and explain (which can sometimes be copy/pastable) or do the adjustments themselves.
What I'm doing is far from perfect, but it's always much much better than nothing. I encourage you to adopt the same attitude. If at any point you're in doubt, find people on IRC #devmo or dev-mdc@lists.mozilla.org

Note You need to log in before you can comment on or make changes to this bug.