Closed Bug 391534 Opened 13 years ago Closed 12 years ago

<preference> with id='' and name='' has unknown type ''

Categories

(Firefox :: Preferences, defect, minor)

defect
Not set
minor

Tracking

()

RESOLVED FIXED

People

(Reporter: jo.hermans, Assigned: florian)

Details

Attachments

(1 file)

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
Summary: preferences ... has unknown type '' → <preference> with id='' and name='' has unknown type ''
Attached patch patch v1Splinter Review
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
Assignee: nobody → florian
Status: NEW → ASSIGNED
Attachment #293750 - Flags: review?(mano)
Whiteboard: [has patch, needs review mano]
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.
Attachment #293750 - Flags: review?(mano) → review+
Severity: normal → minor
OS: Windows XP → All
Hardware: PC → All
Whiteboard: [has patch, needs review mano]
Comment on attachment 293750 [details] [diff] [review]
patch v1

Trivial patch, only prevents a warning from flooding the Error Console.
Attachment #293750 - Flags: approval1.9?
Attachment #293750 - Flags: approval1.9? → approval1.9+
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.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.