301168 - XPath evaluation error causes disabled elements to show

Status: RESOLVED FIXED

(Core Graveyard :: XForms, defect)

Description

[aaronr]

Ran into a testcase that seems to work fine in Novell.  Need to determine if
this should work fine in Mozilla's XForms Processor.  I've simplified down the
testcase a bit yet it still recreates the problem.

Comment 1

[aaronr]

Attachment: testcase

should not see any input fields with text in them.  They should be disabled and
hidden.  However an error encountered processing the expression in @relevant on
the xforms:bind with @id="showInfo" seems to be causing these elements to show
up.

Comment 2

[aaronr]

(In reply to comment #1)
> Created an attachment (id=189659) [edit]
> testcase
> 
> should not see any input fields with text in them.  They should be disabled and
> hidden.  However an error encountered processing the expression in @relevant on
> the xforms:bind with @id="showInfo" seems to be causing these elements to show
> up.

FYI, you'll notice that if you save this testcase locally and if you remove the
[1] from the XPath expressions (since it really isn't necessary), then things
will work just fine.

Comment 3

[aaronr]

looks like it is something to do with the nsXFormsXPathAnalyzer.  In the case
where the binding expression is
instance('employees')/employees/employee[1]/firstname != 'Joe' the expressions
passed to XPath to evaluate are:

'Joe'
'employees'
instance('employees')/employees/employee
first !=

so the last expression is the bad one that causes the error to propagate back up
through transformiix to the bind (rv = NS_ERROR_XPATH_NO_NODE_TYPE_TEST).

Comment 4

[Allan Beaufour]

I'm getting awful tired of fixing bugs in code that I did a temporary+quick+bad
port of :( We should really get some work done on bug 265212.

Comment 5

[Allan Beaufour]

> FYI, you'll notice that if you save this testcase locally and if you remove the
> [1] from the XPath expressions (since it really isn't necessary), then things
> will work just fine.

And that seems to be the problem. The '[1]' is somehow not "accounted" for, and
it's length is added to the 'firstname' part, thus including ' !='.

Comment 6

[Allan Beaufour]

Attachment: Patch

(In reply to comment #4)
> I'm getting awful tired of fixing bugs in code that I did a
temporary+quick+bad
> port of :( We should really get some work done on bug 265212.

It would help if I used more than one brain cell fixing the bugs... bug 296812
messed with the indexes, and I always had a bad feeling about the "+ 2", but
ignored it because I'm less than happy about this code. Stupid me.

Comment 7

[aaronr]

Comment on attachment 189752 [details] [diff] [review]
Patch

fixes testcases

Comment 8

[Allan Beaufour]

Checked in.