Closed Bug 417051 Opened 17 years ago Closed 17 years ago

Range no longer works on the trunk

Categories

(Core Graveyard :: XForms, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: aaronr, Assigned: surkov)

References

Details

Attachments

(2 files, 1 obsolete file)

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] ************************************************************
Attached file testcase (deleted) —
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.
Blocks: 417580
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.
Depends on: 420649
Attached patch patch (obsolete) (deleted) — Splinter Review
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #306967 - Flags: review?(aaronr)
Attachment #306967 - Flags: review?(Olli.Pettay)
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.
Attachment #306967 - Flags: review?(aaronr) → review-
Comment on attachment 306967 [details] [diff] [review] patch ok, probably we should get rid inheritance from DOM element in our control objects.
Attachment #306967 - Flags: review?(Olli.Pettay)
Attached patch patch2 (deleted) — Splinter Review
Attachment #306967 - Attachment is obsolete: true
Attachment #316206 - Flags: review?
Attachment #316206 - Flags: review? → review?(aaronr)
Attachment #316206 - Flags: review?(aaronr) → review+
Attachment #316206 - Flags: review?(Olli.Pettay)
Attachment #316206 - Flags: review?(Olli.Pettay) → review+
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
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Depends on: 467815
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: