280820 - Calculated input field w/type not rendering CSS properly when invalid data entered

Status: RESOLVED DUPLICATE of bug 284101

(Core Graveyard :: XForms, defect)

Description

[Stephen Pride]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050201 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050201 Firefox/1.0+

Note: Intermittent Problem

When an input field is bound as a calculation of other instance elements and
also has a numeric type bound to it, the calculation produces correct results
(i.e., a number if the instance values are numbers, and NaN if one or more
instance values are invalid types - e.g., not xsd:decimal).  However, if CSS is
rendered for invalid input fields, and a user enters an invalid value IN THE
CALCULATED FIELD, the rendering associated with invalid input remains even
though the calculated value is correct.  Through further testing, this problem
is found to be intermittent.  It can even appear/disappear simply by
shift-reloading the page.  I'll add a test case for more clarity of the problem.

Reproducible: Sometimes

Comment 1

[Stephen Pride]

Attachment: Test case that shows the problem

1. Enter a valid numeric value in the first input field.
2. Enter a valid numeric value for the second input field.
3. The third input field should show the sum of the preceding two values.
4. Enter an alphabetic character in the third input field and tab out of the
field.	The field should not display a red color, since it calculates the sum
of the preceding valid values.	However, sometimes it does and sometimes it
doesn't.  You may have to shift-reload a few times to get it to work (or not
work).

Comment 2

[Anne (:annevk)]

How exactly does the selector "xf|*[invalid] input" matches an invalid input
field? Is that some sort of hack, since it seems totally incorrect. (The INPUT
element does not have an ancestor element in the XForms namespace with an
INVALID attribute in the example.)

This might be a separate bug though.

Comment 3

[Doron Rosenberg (IBM)]

(In reply to comment #2)
> How exactly does the selector "xf|*[invalid] input" matches an invalid input
> field? Is that some sort of hack, since it seems totally incorrect. (The INPUT
> element does not have an ancestor element in the XForms namespace with an
> INVALID attribute in the example.)
> 
> This might be a separate bug though.

Since we don't do pseudo classes/elements yet, we use attributes.

xf|*[invalid] matches the invalid xforms element (input in this case), and
styles its anonymous html:input element.

The correct way to just style invalid inputs would be:
xf|input[invalid] - for the whole widget, including label.
xf|input[invalid] input - for the part that you enter text into

Comment 4

[Anne (:annevk)]

For the record, "xf|input:invalid" should not match the same thing as
"xf|input[invalid] xhtml:input" does now.

I can confirm this bug by the way. It has to do with dynamically updating the
CSS, which does not happen. (There are other bugs about that too, actually
slowing down the implementation process of Selectors.)

Comment 5

[Olli Pettay [:smaug][[e-mail]] (holiday -> Aug30)]

(In reply to comment #4) 
> I can confirm this bug by the way. It has to do with dynamically updating the
> CSS, which does not happen. (There are other bugs about that too, actually
> slowing down the implementation process of Selectors.)
I'm not sure if this comment is relevant here?

This bug occurs because we set the invalid attribute when we shouldn't.

Comment 6

[Allan Beaufour]

Bug 284101 fixes the problem.

*** This bug has been marked as a duplicate of 284101 ***