Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007080905 Minefield/3.0a8pre After playing in Tools->Options, I noticed the following warning-message in the Error Console (repeated many times) : <preference> with id='' and name='' has unknown type ''. I tried to see what could have caused it, and I found several sub-dialogs that triggered it when you open the dialog, and then press ok (without really changing something) : Advanced->General->Languages->Choose Advanced->Network->Connection->Settings Content->Javascript->Advanced Content->Fonts&Colors->Advanced Content->Fonts&Colors->Colors Content->File Types->Manage Privacy-Cookies->Show Privacy->Private Data=>Settings etc... It seems that every dialog box that has an 'ok' button triggers these warnings. The ones that have a 'close' button (for instance Privacy-Cookies->Exceptions) don't. Strange. There are a few other bugs that speaks bout this, but in specific dialogs : bug 342254, bug 377001, bug 345599 . Steffen Wilberg has seen it too, see bug 345599 comment 17

The constructor of the preference binding expects that all its attributes are already set. This is the case when the element is created from a <preference> tag in a xul file but it's not the case when it's created with createElement like here: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/content/widgets/preferences.xml&rev=1.74#1074

So, why do you attach the binding (i.e. actually *insert* the element to the document) before setting the attributes? Are you sure everything done in this ctor will be set correctly once you do set the name property?

(In reply to comment #2) > So, why do you attach the binding (i.e. actually *insert* the element to the > document) before setting the attributes? I didn't write this code, but I would guess it's to take advantage of the properties of the binding, instead of setting the attributes. Moreover, in this case the code wants to save the value of the <preference> element to the parent window, so getting the value from the pref system first (what the ctor would do) is really not wanted. > Are you sure everything done in this > ctor will be set correctly once you do set the name property? > The constructor adds an observer for the pref (this will be done correctly when setting the name property) and sets the value to the one stored in the preferences (or the one stored in the parent prefwindow if there is one). Anyway, both of these actions will fail if the name property isn't already set. To get in a consistent state without executing the code of the ctor, you would need to set both the name and the value properties. That's what the code linked in comment 1 does.

Comment on attachment 293750 [details] [diff] [review] patch v1 Please rephrase that to something like "If the element has been inserted without the name attribute set", this has nothing to do with the createElement case in particular. r=mano otherwise.

Comment on attachment 293750 [details] [diff] [review] patch v1 Trivial patch, only prevents a warning from flooding the Error Console.

Checking in toolkit/content/widgets/preferences.xml; /cvsroot/mozilla/toolkit/content/widgets/preferences.xml,v <-- preferences.xml new revision: 1.76; previous revision: 1.75 done Checked in with the rephrased comment, as requested in comment 4.