xf:range doesn't work on the trunk anymore. I see this error in my console: ************************************************************ * Call to xpconnect wrapped JSObject produced this error: * [Exception... "'An error occured throwing an exception' when calling method: [ns IXFormsUIWidget::refresh]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING) " location: "JS frame :: chrome://xforms/content/xforms.xml :: :: line 175" d ata: no] ************************************************************

no slider appears when the testcase is run

I doubt that this is due to XForms. I debugged it down to trying to get this._context in widgets-xhtml.xml I can't even say, dump('AARON: this._context = '+this._context+'\n'); without seeing the failure.

I just separated out all of the range and slider xbl stuff into a standalone .xbl file (removed the xforms dependencies) and tried it on trunk and it worked. So it is somehow related to the fact that XForms is in the mix. But I don't see how that would cause what I'm seeing.

It's pair range widget + slider widget. refresh() method calls min/max/step methods of slider widget and when slider tries to get access to fields then exception thrown. It doesn't matter who calls refresh() method, for example, the same result if it is called from js.

When I make slider widget as <binding id="slider"> <implementation> <field name="_minlabel">null</field> </implementation> </binding> it fails when I call "_minLabel" from js like range.control._minLabel. The magic should be in range widget.

It sounds the problem in getControlElement __proto__: this.ownerDocument. getAnonymousElementByAttribute(this, "anonid", "slider") when I get access to field via control property (getControlElement()) then I fail but if I try it directly then it's ok.

Comment on attachment 306967 [details] [diff] [review] patch Brendan says not to use __proto__ in https://bugzilla.mozilla.org/show_bug.cgi?id=420649#c9 so r-'ing patch. Thanks for figuring out this bug, Alex. This'll be a nice bug to get out of the way.

Comment on attachment 306967 [details] [diff] [review] patch ok, probably we should get rid inheritance from DOM element in our control objects.

Checking in extensions/xforms/resources/content/range-xhtml.xml; /cvsroot/mozilla/extensions/xforms/resources/content/range-xhtml.xml,v <-- range-xhtml.xml new revision: 1.7; previous revision: 1.6 done