Closed Bug 936007 Opened 11 years ago Closed 5 years ago

JavaScript strict warning: chrome://global/content/bindings/tree.xml, line 50: reference to undefined property this.treeBoxObject.columns

Categories

(Core :: XBL, defect)

Product:
Core
Component:
XBL
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: ishikawa, Unassigned)

References

(Depends on 1 open bug)

Details

During the run of |make mozmill| test suite of comm-central thunderbird, I got the warning of the following form 55 times. JavaScript strict warning: chrome://global/content/bindings/tree.xml, line 50: reference to undefined property this.treeBoxObject.columns A program should not access undefined property. This is the top-most frequent "undefined property" bugs: Sharing the top-position with Bug 903636 JavaScript strict warning: chrome://messenger/content/tabmail.xml, line 352: reference to undefined property aTabType.panelId The number at the beginning of the line is the number of appearances of the warning during |make mozmill| test suite run. 55 JavaScript strict warning: chrome://messenger/content/tabmail.xml, line 352: reference to undefined property aTabType.panelId 55 JavaScript strict warning: chrome://global/content/bindings/tree.xml, line 50: reference to undefined property this.treeBoxObject.columns 55 JavaScript strict warning: chrome://global/content/bindings/findbar.xml, line 262: reference to undefined property this._browser.finder 35 JavaScript error: chrome://global/content/bindings/findbar.xml, line 262: this._browser.finder is undefined 12 JavaScript strict warning: chrome://messenger/content/newmailaccount/jquery.tmpl.js, line 123: reference to undefined property def[1] 11 JavaScript strict warning: chrome://global/content/bindings/tree.xml, line 53: reference to undefined property this.treeBoxObject.view 3 JavaScript strict warning: chrome://messenger/content/nsContextMenu.js, line 102: reference to undefined property this.onEditableArea 1 JavaScript strict warning: resource:///modules/dbViewWrapper.js, line 1046: reference to undefined property this._underlyingFolders[0] The code in question on line 50 look like this, and I chose DOM apps because I saw "nsIDOMXULTreeElement" in the comment line slight above it. --- quote <implementation implements="nsIDOMXULTreeElement, nsIDOMXULMultiSelectControlElement"> <!-- ///////////////// nsIDOMXULTreeElement ///////////////// --> 50=> <property name="columns" onget="return this.treeBoxObject.columns;"/> <property name="view" onget="return this.treeBoxObject.view;" onset="return this.treeBoxObject.view = val;"/> --- end quote TIA
Component: DOM: Apps → Untriaged
Product: Core → Thunderbird
See Also: → 936021
I'm seeing Bug 936021 and this bug in SeaMonkey too.
Correct me if I am wrong, I think this should be assigned to core:xbl Correction welcome. TIA
Component: Untriaged → XBL
Product: Thunderbird → Core
This seems really unlikely to be an XBL bug. If you can reproduce this, can you add logging at that spot in the code to see what sort of object this.treeBoxObject is?
Flags: needinfo?(ishikawa)
Depends on: 936021
(In reply to Boris Zbarsky [:bz] from comment #3) > This seems really unlikely to be an XBL bug. If you can reproduce this, can > you add logging at that spot in the code to see what sort of object > this.treeBoxObject is? Will do. Even as of today (April 20th), with the current C-C tree (refreshed last week), I got 55 errors during |make mozmill| test run of debug build of TB. 55 JavaScript strict warning: chrome://messenger/content/tabmail.xml, line 352: reference to undefined property aTabType.panelId => 55 JavaScript strict warning: chrome://global/content/bindings/tree.xml, line 50: reference to undefined property this.treeBoxObject.columns So I will try to printout this.treeBoxObject to figure out what this is then. TIA
Flags: needinfo?(ishikawa)
I added the following code to see if I can print out something when |this.treeBoxObject.columns| is undefined. However, |if| part, especially the first one, which I thought would trigger when this.treeBoxObject.columns is undefined, does not. Does anyone have an idea? What would be the better code? comm-central/mozilla/toolkit/content/widgets/ <!-- ///////////////// nsIDOMXULTreeElement ///////////////// --> <property name="columns" onget="if ( typeof this.treeBoxObject === 'undefined' || typeof this.treeBoxObject.columns === 'undefined' ) dump ('this.treeBoxObject = ' + this.treeBoxObject + ' '); if (this.treeBoxObject == null ) dump ('this.treeBoxObject = null'); return this.treeBoxObject.columns; "/> Initially, I thought maybe dump() was not working, but my adding something like "if (...) { dump(...); xxx; }" where xxx is simply undeclared variable did not trigger the undeclared variable error and so I suspect that |if| expression is indeed not true. I wonder why. I still see the error, JavaScript strict warning: chrome://global/content/bindings/tree.xml, line 50: reference to undefined property this.treeBoxObject.columns when I run |make mozmill| test, but the dumping when this error is triggered failed. Hmm.
> What would be the better code? Just unconditionally dump this.treeBoxObject (and if desired this.treeBoxObject.columns) and see what's dumped right before you get the warning.
This warning can be seen shown just by starting Thunderbird. The output is: Error: [object BoxObject @ 0xe5e68670 (native @ 0xe633dcc4)] Source file: chrome://global/content/bindings/tree.xml Line: 50 this.ID is "threadTree" .
Looks like it could be the TB message list pane, defined here: http://mxr.mozilla.org/comm-central/source/mail/base/content/messenger.xul#409
> Error: [object BoxObject @ 0xe5e68670 (native @ 0xe633dcc4)] That's not terribly surprising, since boxobjects all have classinfo claiming they're "BoxObject". But we got this premably from here: 82 <property name="treeBoxObject" 83 onget="return this.boxObject.QueryInterface(Components.interfaces.nsITreeBoxObject);" 84 readonly="true"/> and hence it QIed to nsITreeBoxObject. And that QI should have flattened the .columns property onto the object. So here's a question: what is the value of "this.treeBoxObject instanceof Components.interfaces.nsITreeBoxObject"?
I think I dig up a very deep problem. [1] 1st simple test: In my previous tests, I could see the issue with session-store/test-session-store.js among others TEST-START | /new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mail/test/mozmill/session-store/test-session-store.js | test_restore_single_3pane_persistence So I picked this single test for testing to save time. Simply adding "+ ' '" to create a string representation of JavaScript objects produced something like "treeBoxObject= [object BoxObject @ 0xb0b4d20 (native @ 0xbe83724)]; " and not terribly useful. So I used JSON.stringify() to see if I could get more meaningful output. (QueryInterface does not seem to produce anything interesting for printing, but this.treeBoxObject does when it has meaningful value.) But then the problem disappeared!? A Heisenberg? Many possibilities: - The issue could be some thread-race issue that is affected by timing change? - We are missing proper locking for critical region handling? - Are we accessing this.treeBoxObject a little too early (before another thread or subsystem can produce something meaningful in .columns property???) - I am not familiar with JavaScript, but is there something like lazy-eval of lisp (and other functional programming langauge) that is used to fill in .columns field (but that does not explain the undefined .columns property. But again, if such framework is used, there may be thread-races in the user-side implementation.) diff --git a/toolkit/content/widgets/tree.xml b/toolkit/content/widgets/tree.xml --- a/toolkit/content/widgets/tree.xml +++ b/toolkit/content/widgets/tree.xml @@ -48,17 +48,18 @@ </xul:hbox> </content> <implementation implements="nsIDOMXULTreeElement, nsIDOMXULMultiSelectControlElement"> <!-- ///////////////// nsIDOMXULTreeElement ///////////////// --> <property name="columns" - onget="return this.treeBoxObject.columns;"/> + onget="dump('\n this.treeBoxObject= ' + + JSON.stringify(this.treeBoxObject) + '; \n' ); return this.treeBoxObject.columns;"/> <property name="view" onget="return this.treeBoxObject.view;" onset="return this.treeBoxObject.view = val;"/> <property name="body" onget="return this.treeBoxObject.treeBody;"/> @@ -75,17 +76,17 @@ onget="return this.getAttribute('seltype')" onset="this.setAttribute('seltype', val); return val;"/> <property name="currentIndex" onget="return this.view ? this.view.selection.currentIndex: - 1;" onset="if (this.view) return this.view.selection.currentIndex = val; return val;"/> <property name="treeBoxObject" - onget="return this.boxObject.QueryInterface(Components.interfaces.nsITreeBoxObject);" + onget=" dump('\n treeBoxObject= ' + this.boxObject.QueryInterface(Components.interfaces.nsITreeBoxObject) + '; \n'); return this.boxObject.QueryInterface(Components.interfaces.nsITreeBoxObject);" readonly="true"/> # contentView is obsolete (see bug 202391) <property name="contentView" onget="return this.view; /*.QueryInterface(Components.interfaces.nsITreeContentView)*/" readonly="true"/> # builderView is obsolete (see bug 202393) <property name="builderView" onget="return this.view; /*.QueryInterface(Components.interfaces.nsIXULTreeBuilder)*/" Here is a typical output A place where the warning was always printed: OLD: ++DOMWINDOW == 14 (0xad4c7b8) [serial = 14] [outer = (nil)] ++DOMWINDOW == 15 (0xb507898) [serial = 15] [outer = 0xad37d20] ++DOMWINDOW == 16 (0xb55c6d8) [serial = 16] [outer = 0xad187d0] JavaScript strict warning: chrome://global/content/bindings/tree.xml, line 50: reference to undefined property this.treeBoxObject.columns GetProp:98: nbytes=64 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv) && subjPrincipal) failed: file /new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/docshell/base/nsDocShell.cpp, line 8470 NEW: With the dump statements above, the warning disappeared. (Note that there seem to be many accesses with two different interface values. ++DOMWINDOW == 14 (0xa1b7978) [pid = 27452] [serial = 14] [outer = (nil)] ++DOMWINDOW == 15 (0xa4e1e48) [pid = 27452] [serial = 15] [outer = 0xa1a8f60] ++DOMWINDOW == 16 (0xab326f8) [pid = 27452] [serial = 16] [outer = 0xa19b048] treeBoxObject.QueryInterface()= [object BoxObject @ 0x93d4e60 (native @ 0xa76afac)]; this.treeBoxObject= {"columns":{"0":{},"1":{},"2":{},"3":{},"4":{},"5":{},"6":{},"7":{},"8":{},"9":{},"10":{},"11":{},"12":{},"13":{},"14":{},"15":{},"16":{},"17":{},"18":{},"threadCol":{},"flaggedCol":{},"attachmentCol":{},"subjectCol":{},"unreadButtonColHeader":{},"senderCol":{},"recipientCol":{},"junkStatusCol":{},"receivedCol":{},"dateCol":{},"statusCol":{},"sizeCol":{},"tagsCol":{},"accountCol":{},"priorityCol":{},"unreadCol":{},"totalCol":{},"locationCol":{},"idCol":{}},"view":{},"focused":false,"treeBody":{},"rowHeight":18,"rowWidth":0,"horizontalPosition":0,"selectionRegion":{}}; treeBoxObject.QueryInterface()= [object BoxObject @ 0x93d4e60 (native @ 0xa76afac)]; treeBoxObject.QueryInterface()= [object BoxObject @ 0x93d4e60 (native @ 0xa76afac)]; this.treeBoxObject= {"columns":{"0":{},"1":{},"2":{},"3":{},"4":{},"5":{},"6":{},"7":{},"8":{},"9":{},"10":{},"11":{},"12":{},"13":{},"14":{},"15":{},"16":{},"17":{},"18":{},"threadCol":{},"flaggedCol":{},"attachmentCol":{},"subjectCol":{},"unreadButtonColHeader":{},"senderCol":{},"recipientCol":{},"junkStatusCol":{},"receivedCol":{},"dateCol":{},"statusCol":{},"sizeCol":{},"tagsCol":{},"accountCol":{},"priorityCol":{},"unreadCol":{},"totalCol":{},"locationCol":{},"idCol":{}},"view":{},"focused":false,"treeBody":{},"rowHeight":18,"rowWidth":0,"horizontalPosition":0,"selectionRegion":{}}; treeBoxObject.QueryInterface()= [object BoxObject @ 0x93d4e60 (native @ 0xa76afac)]; (CI comment: now the QueryInterface value seems to switch here.) treeBoxObject.QueryInterface()= [object BoxObject @ 0xab8fa00 (native @ 0xa6b61ac)]; (CI comment: the following seems to indicate some type of empty selection? empty folder?) this.treeBoxObject= {"columns":{"0":{},"folderNameCol":{}},"view":{},"focused":false,"treeBody":{},"rowHeight":18,"rowWidth":0,"horizontalPosition":0,"selectionRegion":{}}; treeBoxObject.QueryInterface()= [object BoxObject @ 0xab8fa00 (native @ 0xa6b61ac)]; treeBoxObject.QueryInterface()= [object BoxObject @ 0xab8fa00 (native @ 0xa6b61ac)]; this.treeBoxObject= {"columns":{"0":{},"folderNameCol":{}},"view":{},"focused":false,"treeBody":{},"rowHeight":18,"rowWidth":0,"horizontalPosition":0,"selectionRegion":{}}; treeBoxObject.QueryInterface()= [object BoxObject @ 0xab8fa00 (native @ 0xa6b61ac)]; GetProp:98: nbytes=64 [27452] WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv) && subjPrincipal) failed: file /new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/docshell/base/nsDocShell.cpp, line 8687 At least .columns is no longer undefined. So there is a Heisenberg effect... [2]: full |make mozmill| test. After observing the above using a single test target file, I ran full |make mozmill| test. Then I dug up a more serious issue here. I have been running the full |make mozmill| test, and with the dump statement above, the particular warning is no longer issued. So I think there is a timing issue of a sort. That is now confirmed. *BUT* then I see new errors, "cyclic object value" (stack trace from EXCEPTION below), meaning that - a possibility : the time-race issue now change the processing such a manner to create a cyclic data structure!? (which used to end up with UNDEFINED .columns) and processing now cannot proceed since somewhere the cyclic data produced overflowing of internal data buffer. - it is possible that dump() of this.treeBoxObject itself is causing the traversing of cyclic data structure resulting in the error. I think this particular exception quoted below IS an overflow of .columns property since, I see |get_columns tree.xml:50| near the top of the stack. SO, the particular test program in TB silently produced a CIRCULAR data structure for some reason, but since no user is looking at the whole of the structure (only the head of the data structure must be checked, no body complained before until I came along and printed its content using JSON.stringify ! Quote from a test failure: SUMMARY-UNEXPECTED-FAIL | test-display-name.js | test-display-name.js::test_from_display_name_unquoted EXCEPTION: cyclic object value at: tree.xml line 50 get_columns tree.xml:50 1 check_display_name test-display-name.js:183 1 Runner.prototype.wrapper frame.js:585 9 Runner.prototype._runTestModule frame.js:655 9 Runner.prototype.runTestModule frame.js:701 3 Runner.prototype.runTestDirectory frame.js:525 7 runTestDirectory frame.js:707 3 Bridge.prototype._execFunction server.js:179 3 Bridge.prototype.execFunction server.js:183 1 Session.prototype.receive server.js:283 3 AsyncRead.prototype.onDataAvailable server.js:88 3 In another case, the cyclic data seems to be created during startup. Note the error "System JS : ERROR chrome://global/content/bindings/tree.xml:50 - TypeError: cyclic object value" in the quote below. TEST-START | /new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mail/test/mozmill/subscribe/test-subscribe-news-filter.js | test_subscribe_newsgroup_filter Step Pass: {"function": "Controller.keypress()"} Step Pass: {"function": "Controller.keypress()"} Step Pass: {"function": "Controller.keypress()"} Step Pass: {"function": "Controller.keypress()"} Step Pass: {"function": "Controller.keypress()"} Step Pass: {"function": "Controller.keypress()"} Step Pass: {"function": "Controller.keypress()"} Step Pass: {"function": "Controller.keypress()"} Step Pass: {"function": "Controller.keypress()"} Step Pass: {"function": "Controller.keypress()"} Step Pass: {"function": "Controller.keypress()"} Step Pass: {"function": "Controller.keypress()"} Step Pass: {"function": "Controller.keypress()"} Step Pass: {"function": "Controller.keypress()"} Step Pass: {"function": "Controller.keypress()"} Step Pass: {"function": "Controller.keypress()"} Step Pass: {"function": "Controller.keypress()"} treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; this.treeBoxObject= {"columns":{"0":{},"1":{},"nameColumn2":{},"subscribedColumn2":{}},"view":{},"focused":false,"treeBody":{},"rowHeight":18,"rowWidth":327,"horizontalPosition":0,"selectionRegion":{}}; treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; this.treeBoxObject= {"columns":{"0":{},"1":{},"nameColumn2":{},"subscribedColumn2":{}},"view":{},"focused":false,"treeBody":{},"rowHeight":18,"rowWidth":327,"horizontalPosition":0,"selectionRegion":{}}; treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; this.treeBoxObject= {"columns":{"0":{},"1":{},"nameColumn2":{},"subscribedColumn2":{}},"view":{},"focused":false,"treeBody":{},"rowHeight":18,"rowWidth":327,"horizontalPosition":0,"selectionRegion":{}}; treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; System JS : ERROR chrome://global/content/bindings/tree.xml:50 - TypeError: cyclic object value GetProp:98: nbytes=16 GetProp:98: nbytes=16 treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; System JS : ERROR chrome://global/content/bindings/tree.xml:50 - TypeError: cyclic object value treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; System JS : ERROR chrome://global/content/bindings/tree.xml:50 - TypeError: cyclic object value treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; System JS : ERROR chrome://global/content/bindings/tree.xml:50 - TypeError: cyclic object value treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; System JS : ERROR chrome://global/content/bindings/tree.xml:50 - TypeError: cyclic object value treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; System JS : ERROR chrome://global/content/bindings/tree.xml:50 - TypeError: cyclic object value treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; treeBoxObject.QueryInterface()= [object BoxObject @ 0xbef4678 (native @ 0xbefc174)]; System JS : ERROR chrome://global/content/bindings/tree.xml:50 - TypeError: cyclic object value My guess: Thread-race causing multiple-threads working on a single data structure to produce cyclic data by stomping on each other's toes sounds a very plausible explanation. Somewhere we don't have the proper lock ? TIA
(In reply to Boris Zbarsky [:bz] from comment #9) > So here's a question: what is the value of "this.treeBoxObject instanceof > Components.interfaces.nsITreeBoxObject"? That returns 'true' right before we get the referenceError.
> - The issue could be some thread-race issue that is affected by timing > change? > - We are missing proper locking for critical region handling? All these objects are only accessed from one thread. > - Are we accessing this.treeBoxObject a little too early (before another > thread or subsystem can produce something meaningful in .columns property???) The only way that could happen is if it's not an nsITreeBoxObject or something. > - I am not familiar with JavaScript, but is there something like > lazy-eval of lisp (and other functional programming langauge) that > is used to fill in .columns field There is, but the QI should be taking care of that. A more plausible hypothesis than any of those is that the JS engine is blaming the wrong property access here. > "cyclic object value" (stack trace from EXCEPTION below), meaning that Yes, JSON.stringify will throw when given a cyclic data structures, which are pretty common in JS... > Thread-race causing multiple-threads working on a single data > structure to produce cyclic data All these data structures are only accessed from one thread.
Thank you for your comment. (In reply to Boris Zbarsky [:bz] from comment #12) > > - The issue could be some thread-race issue that is affected by timing > > change? > > - We are missing proper locking for critical region handling? > > All these objects are only accessed from one thread. That's good news. [...] > A more plausible hypothesis than any of those is that the JS engine is > blaming the wrong property access here. Hmm... I wonder what I can do then here. Inserting some probes to JS engine where it detects an undefined property? Any ideas. What bothers me is that this, undefined property message is gone AFTER dumping the data using JSON.stringify() which suggests to me some timing-related issues. (So far, the underlying JS engine did not produce false positive. So I am tempted to think there are timing issues still. But then there may be corner cases where JS engine fails to handle some almost ?undefined? cases. I don't know the details of JS engine and so can't fathom a situation where such things happen.) > > "cyclic object value" (stack trace from EXCEPTION below), meaning that > > Yes, JSON.stringify will throw when given a cyclic data structures, which > are pretty common in JS... Is cyclic data structure common in Mozilla's code? I was not so sure, but given some search results I found using google, it seems it is relatively easy to produce cyclic code without realizing it for a JS programmer that interferes with JSON.stringify(). (This is very different from, say, Lisp, where you really need to go out of your normal way to create circular list. Common Lisp has a serializer to print and read such cyclic data structure to take care cyclic list structure.) > All these data structures are only accessed from one thread. Again, this should excludes thread races. TIA
> Hmm... I wonder what I can do then here. Add explicit tests to see whether the property is in fact undefined and see what those say? > which suggests to me some timing-related issues. Console messages are logged asynchronously. > Is cyclic data structure common in Mozilla's code? Sure. For example, the entire DOM is one big cyclic data structure.
(In reply to Boris Zbarsky [:bz] from comment #14) > > Hmm... I wonder what I can do then here. > > Add explicit tests to see whether the property is in fact undefined and see > what those say? > > > which suggests to me some timing-related issues. OK, I will check this. Hmm, all I want is a "rock-solid mail client (tm)". I never thought I would be checking the sanity of JS engine. > > Console messages are logged asynchronously. > > > Is cyclic data structure common in Mozilla's code? > > Sure. For example, the entire DOM is one big cyclic data structure. Wow, I did not realize that. So we better be prepared for that eventuality, although the particular field |.columns| does not seem to need cyclic data structure usually. TIA
(In reply to ISHIKAWA, Chiaki from comment #15) > (In reply to Boris Zbarsky [:bz] from comment #14) > > > Hmm... I wonder what I can do then here. > > > > Add explicit tests to see whether the property is in fact undefined and see > > what those say? > > > > > which suggests to me some timing-related issues. > > OK, I will check this. Hmm, all I want is a "rock-solid mail client (tm)". I > never thought I would be checking the sanity of JS engine. > Here is what I found out. OK, it seems that JS Engine's idea of the situation of printing of "reference to undefined property" is not quite what typical methods which many documents suggest to catch undefined property can catch!? Suggested method: if (typeof( var.property ) === 'undefined') ... Or, maybe, a property that is defined/used elsewhere may trigger different printing behavior (maybe buggy JS Engine behavior). I modified the code in tree.xml as follows. Printing |.columns| field only avoided the printing of circular data structure issue, too, it seems. (I non longer get cyclic error from |make mozmill|.) <implementation implements="nsIDOMXULTreeElement, nsIDOMXULMultiSelectControlElement"> <!-- ///////////////// nsIDOMXULTreeElement ///////////////// --> <property name="columns" onget=" if (typeof (this.treeBoxObject.columns) === 'undefined') dump('\n dump UNDEFINED\n'); if (typeof (this.treeBoxObject.xxyyz) === 'undefined') dump('\n dump xxyyz UNDEFINED\n'); if (typeof (this.treeBoxObject.XxYyz) === 'undefined') dump('\n dump XxYyz UNDEFINED \n'); dump('\n this.treeBoxObject.columns = ' + JSON.stringify(this.treeBoxObject.columns) + '; \n' ); return this.treeBoxObject.columns; "/> <property name="view" Note that property, xxyyz and XxYyZ, are not defined and used for treeBoxObject anywhere in the code. So it should cause the if(typeof ...) dump(...) to be executed and it IS executed. (Note, |'undefined'| must be used, and |undefined| does not work.) But when JS engine prints out "reference to undefined property this.treeBoxObject.columns", my if expression to catch it did not trigger. Below is the excerpt of the log near where the original undefined warning was observed. I see the "undefined property" again, but note the dump for |xxyyz|, |XxYyz|, but missing dump for |this.treeBoxObject.columns| itself. Something is indeed strange. ==== QUOTE BEGIN ++DOMWINDOW == 14 (0x3d2e780) [pid = 10451] [serial = 14] [outer = (nil)] ++DOMWINDOW == 15 (0x47c34b0) [pid = 10451] [serial = 15] [outer = 0x3d1ab80] ++DOMWINDOW == 16 (0x4833b50) [pid = 10451] [serial = 16] [outer = 0x3ce9310] treeBoxObject.QI= [object BoxObject @ 0x2ba7bb0 (native @ 0x4405418)]; JavaScript strict warning: chrome://global/content/bindings/tree.xml, line 50: reference to undefined property this.treeBoxObject.columns treeBoxObject.QI= [object BoxObject @ 0x2ba7bb0 (native @ 0x4405418)]; dump xxyyz UNDEFINED treeBoxObject.QI= [object BoxObject @ 0x2ba7bb0 (native @ 0x4405418)]; dump XxYyz UNDEFINED treeBoxObject.QI= [object BoxObject @ 0x2ba7bb0 (native @ 0x4405418)]; this.treeBoxObject.columns = {"0":{},"1":{},"2":{},"3":{},"4":{},"5":{},"6":{},"7":{},"8":{},"9":{},"10":{},"11":{},"12":{},"13":{},"14":{},"15":{},"16":{},"17":{},"18":{},"threadCol":{},"flaggedCol":{},"attachmentCol":{},"subjectCol":{},"unreadButtonColHeader":{},"senderCol":{},"recipientCol":{},"junkStatusCol":{},"receivedCol":{},"dateCol":{},"statusCol":{},"sizeCol":{},"tagsCol":{},"accountCol":{},"priorityCol":{},"unreadCol":{},"totalCol":{},"locationCol":{},"idCol":{}}; treeBoxObject.QI= [object BoxObject @ 0x2ba7bb0 (native @ 0x4405418)]; treeBoxObject.QI= [object BoxObject @ 0x2ba7bb0 (native @ 0x4405418)]; treeBoxObject.QI= [object BoxObject @ 0x2ba7bb0 (native @ 0x4405418)]; dump xxyyz UNDEFINED treeBoxObject.QI= [object BoxObject @ 0x2ba7bb0 (native @ 0x4405418)]; dump XxYyz UNDEFINED --- If this.treeBoxObject.columns is indeed 'undefined', then |if (typeof (this.treeBoxObject.columns) === 'undefined') dump('\n dump UNDEFINED\n')| should be executed as a whole and we ought to see the output, "dump UNDEFINED", but we don't seem to. (Is it possible that dump() is disabled (debug = false?) at the startup until it is enabled later???) Should I file a bug for JS Engine, or solicit feedback and/or clarification in mozilla's java newsgroups? TIA
(In reply to ISHIKAWA, Chiaki from comment #16) > Should I file a bug for JS Engine, or solicit feedback and/or clarification > in mozilla's java newsgroups? > I am asking about JS Engine issue in dev-js-engine mailing list / mozilla.dev.tech.js-engine newsgroup now. https://groups.google.com/forum/#!topic/mozilla.dev.tech.js-engine/EkJwTOZUmv0

XBL is now disabled in Firefox (Bug 1583314) and is in the process of being removed from Gecko (Bug 1566221), so closing bugs requesting changes to its implementation as wontfix.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.