XPath evaluation error causes disabled elements to show

RESOLVED FIXED

Status

RESOLVED FIXED
14 years ago
3 years ago

People

(Reporter: aaronr, Assigned: allan)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

2.59 KB, application/xhtml+xml
Details
763 bytes, patch
aaronr
: review+
doronr
: review+
Details | Diff | Splinter Review
(Reporter)

Description

14 years ago
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.
(Reporter)

Comment 1

14 years ago
Created attachment 189659 [details]
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.
(Reporter)

Comment 2

14 years ago
(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.
(Reporter)

Comment 3

14 years ago
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).
(Assignee)

Comment 4

14 years ago
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.
(Assignee)

Comment 5

14 years ago
> 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 ' !='.
(Assignee)

Comment 6

14 years ago
Created attachment 189752 [details] [diff] [review]
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.
Assignee: aaronr → allan
Status: NEW → ASSIGNED
Attachment #189752 - Flags: review?(aaronr)
(Reporter)

Comment 7

14 years ago
Comment on attachment 189752 [details] [diff] [review]
Patch

fixes testcases
Attachment #189752 - Flags: review?(aaronr) → review+
(Assignee)

Updated

14 years ago
Attachment #189752 - Flags: review?(doronr)
Attachment #189752 - Flags: review?(doronr) → review+
(Assignee)

Comment 8

14 years ago
Checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.