Closed Bug 553579 Opened 10 years ago Closed 10 years ago

(void 0) is undefined -- cryptic error


(Core :: JavaScript Engine, defect)

Not set





(Reporter: protz, Unassigned)



(1 file)

2.38 KB, application/vnd.mozilla.xul+xml
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100317 Namoroka/3.6.3pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a4pre) Gecko/20100319 Shredder/3.2a1pre

It seems that when I use certain properties of iframes, I get this unbelievably cryptic error. My code used to work fine on the official builds (latest-comm-1.9.1) so I don't know if I should blame x86_64, comm-central or mozilla-central... anyway, looks like a core Javascript error so I hope I'm filing for the right component here. This might also be a DOM thing since this has to do with iframes.

Reproducible: Always

Steps to Reproduce:
I insist on specifying that this code worked perfectly fine before (before = all Thunderbird releases from 3.0a1 to 3.1b1). Here's two examples of lines that trigger such behaviour:

for each (let [, a] in Iterator(iframe.contentDocument.getElementsByTagName("a"))) {


for each (let [, child] in Iterator(aNode.childNodes)) {

aNode is equal to iframe.contentDocument.body here.

iframe is defined using :

let iframe = htmlpane.contentDocument.createElementNS("", "iframe");

I might be doing something "wrong" or relying on some unstable behaviour (although I doubt it). I'm just creating an iframe, adding event listeners and walking its DOM once the content is properly loaded (I have two load events: the first one when the iframe is inserted (url is about:blank) and the second one when I call loadURI myself).

I will try to create a reduced testcase and post it here if I have the time.
I just recompiled Thunderbird 3.1beta1 against Gecko 1.9.1 and the bug disappeared. As I said, I'll try to come up with some more information when I have the time.
I dimly recall a bug we fixed. You may have to bisect to find it, or search the closed decompiler bugs.

Whiteboard: DUPEME
This is similar to bug 420919 but I'm not sure it's the same kind of error. Just to make things clear : the bug wasn't present in Gecko 1.9.1 but is present in mozilla-central. I'll run a bisection next week and try to determine when the changes were introduced.
The bug has been present ever since the first 3.2a1pre nightly of Thunderbird was built. (see It's not present on the 3.1 branch which means it's definitely linked to the Gecko version.

As this is a Thunderbird extension that demonstrates the issue, I'll try to come up with a testcase in a regular webpage so that I can run mozregression on Firefox. Stay tuned :).
Attached file The testcase
I'm adding a very minimal testcase. When viewing this page inside a tab in Firefox, if you click the link, the error console will display

"Error: (void 0) is undefined
Source File: file:///tmp/test.xul
Line: 48"

I will try to run a mozregression on that. I'd be glad if someone could confirm this.
Actually the link is useless, just loading the page is enough. Sorry for the noise.
Hmm.  (void 0) is the first element of your array there (the one before "elt").  Is that a valid usage of iterators?
Er, no, sorry I forgot to mention that, the testcase is definitely *wrong*. Since the iterator is called without parameters, there's nothing to iterate on, so there must be an error. I simply wanted to emphasize the fact that the error message is not informative at all.

As to the destructuring assignment pattern, I think it's used quite often, at least in the code I'm reading right now, namely
But your earlier testcases did pass something to Iterator, and still had this error?
I think there's two separate issues here.
i) "(void 0) is undefined" when using let [, foo] = Iterator(null)
ii) what's inside Iterator() being null in the first testcase.

I think the testcase I just sent demonstrates the first issue clearly.

As to the second issue, I still haven't figured out why trying to access my iframes fails so badly in Thunderbird 3.2 and not earlier versions. I'm a bit worried that my iframe (created dynamically using createElementNS) has a contentDocument but that the contentDocument is unusable, but I haven't been able to find out the root cause of it, nor was I able to reproduce it simply. It's very weird that such code works in Tb 3.0, 3.1 but not 3.2.

          let iframe = htmlpane.contentDocument.createElementNS("", "iframe");
          iframe.setAttribute("type", "content");
          /* The xul:iframe automatically loads about:blank when it is added
           * into the tree. We need to wait for the document to be loaded before
           * doing things.
           * Why do we do that ? Basically because we want the <xul:iframe> to
           * have a docShell and a webNavigation. If we don't do that, and we
           * set directly src="about:blank" in the XML above, sometimes we are
           * too fast and the docShell isn't ready by the time we get there. */
          iframe.addEventListener("load", function f_temp2(event) {
              iframe.removeEventListener("load", f_temp2, true);

              /* The second load event is triggered by loadURI with the URL
               * being the necko URL to the given message. */
              iframe.addEventListener("load", function f_temp1(event) {
                  iframe.removeEventListener("load", f_temp1, true);

                  /* The part below is all about quoting */
                  let iframeDoc = iframe.contentDocument;
                  //ACCESS iframeDoc.body.childNodes, ERROR

                  /* Here ends the chain of event listeners, nothing happens
                   * after this. */
                }, true); /* end document.addEventListener */

              let url = msgHdrToNeckoURL(msgHdr, gMessenger);
              let cv = iframe.docShell.contentViewer;
              cv.hintCharacterSet = "UTF-8";
              cv.hintCharacterSetSource = kCharsetFromMetaTag;
              iframe.docShell.appType = Components.interfaces.nsIDocShell.APP_TYPE_MAIL;
              iframe.webNavigation.loadURI(url.spec+"?header=quotebody", iframe.webNavigation.LOAD_FLAGS_IS_LINK, null, null, null);
            }, true); /* end document.addEventListener */


Above is the main structure of the code that triggers the error. I think I'm going to try to reproduce the issue when I have time, and then file a separate bug report as soon as I understand better what's happening here.
You're using capturing listeners, so probably getting the load events for images, etc.  You need to check your event targets.  We didn't use to properly handle capturing for load events.

And that about:blank thing the comment is about... that might stop happening (and stop firing the load event, therefore).  But that's for future.
After some further investigation, it turns out that :
- let [a, b] = null indeed gives "(void 0) is undefined", so that definitely should be fixed to give something more informative, that's what we were discussing before.
- there is another much more serious issue regarding Iterator and XPCNativeWrappers.

I've uploaded a sample .xpi (I could only trigger this in chrome code). I've reduced the issue to a very minimalistic testcase involving iframes (50 lines including XUL markup). It's here

Steps to reproduce:
- install the .xpi
- enable dump in the console
- from the Error console, run open("chrome://testcase5/content/testcase.xul", "", "chrome,width=500,height=500");
- click "add iframe"
- click "load some content"

Basically, the Iterator object no longer works well with XPCNativeWrappers (it used to work fine in 1.9.2).

          dump("direct access works: "+iframe.contentDocument.body.childNodes[0]+"\n");
          for each (let x in Iterator(iframe.contentDocument.body.childNodes)) {
            dump("x is "+x+"\n");

Iterator is well-defined, childNodes is non-null, has length > 0, so everything should be fine.

In both 1.9.3 and 1.9.2 the first dump gives "[object XPCNativeWrapper [object Text]]"

In 1.9.3 (Firefox 3.7a4), I get "x is undefined" as the result of the second dump().
In 1.9.2 (Firefox 3.6) I get "x is 0,[object XPCNativeWrapper [object Text]]"

If I remove the type="content" on my iframe, I no longer have an issue on 1.9.3.

This is probably a regression. A quick bugzilla search doesn't give any bugs, so I will probably file a new bug regarding this issue. BTW, I usually hangout in #maildev if you need some more information (:protz).
Please cc me on the follow up-bug wrt to wrapper iteration.
Follow up is bug 566846 for the XPCNativeWrappers sub-issue (patch pending). I'm leaving this bug as is because the "cryptic error" still shows up with

let [a, b] = null
With tm tip I get

js> let [a, b] = null
typein:1: TypeError: null has no properties

Is this cryptic? It's pretty accurate. It could cite the index being accessed (0, for the a let-binding), but not sure that's worth its weight.

I think that's pretty ok. I wasn't using latest tracemonkey tip, which is why I still had this "(void 0) is undefined" error, so I'm marking as closed.

I guess I'm more used to functional-style error messages such as "type error: null has type unit but and expression was expected of type array" or something similar, but it's not relevant here :).
Closed: 10 years ago
Resolution: --- → WORKSFORME
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.