If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

XPath evaluation error causes disabled elements to show

RESOLVED FIXED

Status

Core Graveyard
XForms
RESOLVED FIXED
12 years ago
a year ago

People

(Reporter: aaronr, Assigned: Allan Beaufour)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

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

Description

12 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

12 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

12 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

12 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

12 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

12 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

12 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

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

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

Updated

12 years ago
Attachment #189752 - Flags: review?(doronr)

Updated

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

Comment 8

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