Comment 35 for bug 605513

During test for bug 831664, funny phenomenon was observed.
(0) A customized ToolBar button does following.
(a) Write data of some wrapped objects and text messages to Error Console:
    - incomingServer.isGMailServer/trasfFolderName and some other attributes.
    - some properties of some other wrapped objects.
(b) Sometimes, change incomingServer.isGMailServer/trashFolderName value
    when value is normally returned.
(c) Sometimes, try to change incomingServer.isGMailServer/trashFolderName value
    even if it's undefined(=> Exception of this bug occurs)
(d) Sometimes, writes very-long/multi-line text to Error Console.
    var msg=new Array();for(var key in obj){msg[msg.length]=key+" = "+obj[key];}
    var text=msg.join("\n"); Write text to Error Console;

(1) After restart of Thunderbird, while doing (a)/(b)/(c), undefined is returned for isGMailServer/trashFolderName.
(2) When (d) is executed one or a few times("clear Error Console or not" seems irrelevant), isGMailServer/trashFolderName is normally returned suddenly for (a)/(b)/(c). Because isGMailServer/trashFolderName is not undefined, change of property value is successful.
(3) After (2), if (a)/(b)/(c) is executed after some other operations in Thunderbird(account switch, account collapse/expand etc.), undefined is suddenly returned again for isGMailServer/trashFolderName.
(4) After (3), if (d) is executed one(or a few) times, isGMailServer/trashFolderName is normally returned again for (a)/(b)/(c) => Returns to step (2).

Why wrapped object's property value depends on length of JavaScript string data and/or Error Console log data volume?

Wrapper tries to refer to non-existent memory address, or object which is not released yet by Garbage Collector after Destroy Object?
(if garbage data is fortunately held at referred memory address, object's property is successfully shown.)
Or similar problem in object initialization/update by Thunderbird?