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?
During test for bug 831664, funny phenomenon was observed. isGMailServer/ trasfFolderName and some other attributes. isGMailServer/ trashFolderName value isGMailServer/ trashFolderName value multi-line text to Error Console. msg.length] =key+" = "+obj[key];} join("\ n"); Write text to Error Console;
(0) A customized ToolBar button does following.
(a) Write data of some wrapped objects and text messages to Error Console:
- incomingServer.
- some properties of some other wrapped objects.
(b) Sometimes, change incomingServer.
when value is normally returned.
(c) Sometimes, try to change incomingServer.
even if it's undefined(=> Exception of this bug occurs)
(d) Sometimes, writes very-long/
var msg=new Array();for(var key in obj){msg[
var text=msg.
(1) After restart of Thunderbird, while doing (a)/(b)/(c), undefined is returned for isGMailServer/ trashFolderName . trashFolderName is normally returned suddenly for (a)/(b)/(c). Because isGMailServer/ trashFolderName is not undefined, change of property value is successful. trashFolderName . trashFolderName is normally returned again for (a)/(b)/(c) => Returns to step (2).
(2) When (d) is executed one or a few times("clear Error Console or not" seems irrelevant), isGMailServer/
(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/
(4) After (3), if (d) is executed one(or a few) times, isGMailServer/
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? update by Thunderbird?
(if garbage data is fortunately held at referred memory address, object's property is successfully shown.)
Or similar problem in object initialization/