Closed Bug 312848 Opened 15 years ago Closed 15 years ago
XPath expressions using namespaces inside repeats generate error messages
Here's the relevant part of my XForms (chopped off unnecessary parts): <xf:repeat id="job-repeat" nodeset="instance('jobsFile')/jobs:Jobs/jobs:Job[position()!=last()]"> <xf:input bind="job-parentslotid-bind"> <xf:label>Slot</xf:label> </xf:input> <xf:select1 ref="jobs:Description"> <xf:label>Job</xf:label> <xf:item> <xf:label>INterconnection check before starting</xf:label> <xf:value>INterconnection check before starting</xf:value> </xf:item> <xf:item> <xf:label>IWP01.020 Main superconduct. cables soldering</xf:label> <xf:value>IWP01.020 Main superconduct. cables soldering</xf:value> </xf:item> <xf:alert>The job does not exist!</xf:alert> </xf:select1> <xf:output ref="jobs:ExecutedBy"> <xf:label>Executed by</xf:label> </xf:output> </xf:repeat>
I see the same, and yes only for controls inside a repeat using namespaces in their expressions, like ref="be:x".
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: @ref and @bind in repeats generate unnecessary error messages → XPath expressions using namespaces inside repeats generate error messages
The failure starts here: http://lxr.mozilla.org/seamonkey/source/extensions/transformiix/source/xpath/ExprParser.cpp#688
Problem was, that we (I) were cloning children into the contextcontainer, before inserting the cc into the repeat... I vaguely remember having done that for a reason, but that's lost on me. This patch inserts the cc into the repeat before inserting children. That makes the namespace lookup succeed. It also removes some dead code from nsXFormsUtils.
Attachment #202246 - Flags: review?(aaronr)
Comment on attachment 202246 [details] [diff] [review] Patch >+ // Insert context node >+ nsCOMPtr<nsIDOMNode> domNode; >+ rv = mHTMLElement->AppendChild(riElement, getter_AddRefs(domNode)); >+ NS_ENSURE_SUCCESS(rv, rv); >+ nit: please comment why you are adding this node before populating it with children since it seems contrary to what we do in other places. And in case someone thinks about moving it back in the future for some other reason, they'll at least know a problem that it could cause.
Attachment #202246 - Flags: review?(aaronr) → review+
Checked into trunk
Thanks a lot! Keep up the great work! Too bad I have to wait for the next nightly build to test it ;-)
(In reply to comment #9) > Thanks a lot! Keep up the great work! > > Too bad I have to wait for the next nightly build to test it ;-) Well, that's all up to you: http://developer.mozilla.org/en/docs/Build_Documentation ;-)
checked into MOZILLA_1_8_BRANCH via bug 323691. Leaving open for now until it gets into 1.8.0
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
verfied fixed on MOZILLA_1_8_BRANCH
You need to log in before you can comment on or make changes to this bug.