Last Comment Bug 312848 - XPath expressions using namespaces inside repeats generate error messages
: XPath expressions using namespaces inside repeats generate error messages
Status: RESOLVED FIXED
: fixed1.8.0.2, fixed1.8.1
Product: Core Graveyard
Classification: Graveyard
Component: XForms (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: aaronr
: Stephen Pride
:
Mentors:
Depends on:
Blocks: 264329
  Show dependency treegraph
 
Reported: 2005-10-18 07:11 PDT by Victor Engmark
Modified: 2016-07-15 14:46 PDT (History)
3 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Testcase (1.22 KB, application/xhtml+xml)
2005-10-20 02:06 PDT, Allan Beaufour
no flags Details
Patch (3.66 KB, patch)
2005-11-08 06:32 PST, Allan Beaufour
aaronr: review+
Details | Diff | Splinter Review
Added comment (3.81 KB, patch)
2005-11-14 00:59 PST, Allan Beaufour
bugs: review+
Details | Diff | Splinter Review

Description Victor Engmark 2005-10-18 07:11:44 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051017 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051017 Firefox/1.6a1

Each "output", "input", and "select1" element inside a repeat will generate an
error in the JavaScript Console for each top node in the repeat nodeset. This
happens even if the data of these elements are shown according to the @bind /
@ref in the output.

The result is the same when using relative references, absolute references, or
binds.

Reproducible: Always

Steps to Reproduce:
1. Add a repeat to your XForms, with @nodeset
2. Add an "output", "input", or "select1" element inside the repeat
3. Bind these to instance data using @ref or @bind
Actual Results:  
Results are shown, but "size(repeat nodeset) * count(elements with @ref or @bind
in the repeat)" errors show up for the repeat.

Expected Results:  
Results are shown without any errors.

Typical error message: "Error: XForms Error (10): Error parsing XPath
expression: jobs:Description".

Moving the "offending" elements outside the repeat still results in output (if
the reference is absolute), but no errors.
Comment 1 Victor Engmark 2005-10-18 07:18:13 PDT
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>
Comment 2 Allan Beaufour 2005-10-20 02:04:31 PDT
I see the same, and yes only for controls inside a repeat using namespaces in
their expressions, like ref="be:x".
Comment 3 Allan Beaufour 2005-10-20 02:06:01 PDT
Created attachment 200181 [details]
Testcase
Comment 5 Allan Beaufour 2005-11-08 06:32:45 PST
Created attachment 202246 [details] [diff] [review]
Patch

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.
Comment 6 aaronr 2005-11-08 14:44:39 PST
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.
Comment 7 Allan Beaufour 2005-11-14 00:59:14 PST
Created attachment 202964 [details] [diff] [review]
Added comment
Comment 8 Allan Beaufour 2005-11-15 22:50:26 PST
Checked into trunk
Comment 9 Victor Engmark 2005-11-16 01:43:47 PST
Thanks a lot! Keep up the great work!

Too bad I have to wait for the next nightly build to test it ;-)
Comment 10 Allan Beaufour 2005-11-16 01:56:23 PST
(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

;-)
Comment 11 aaronr 2006-02-02 17:24:50 PST
checked into MOZILLA_1_8_BRANCH via bug 323691.  Leaving open for now until it gets into 1.8.0
Comment 12 aaronr 2006-07-07 10:10:27 PDT
verfied fixed on MOZILLA_1_8_BRANCH

Note You need to log in before you can comment on or make changes to this bug.