Last Comment Bug 344693 - Select1 selection gives invalid state
: Select1 selection gives invalid state
Product: Core Graveyard
Classification: Graveyard
Component: XForms (show other bugs)
: Trunk
: Other All
-- normal (vote)
: ---
Assigned To: xforms
: Stephen Pride
Depends on:
  Show dependency treegraph
Reported: 2006-07-14 10:04 PDT by Josef Spillner
Modified: 2016-07-15 14:46 PDT (History)
0 users
See Also:
QA Whiteboard:
Iteration: ---
Points: ---

testcase 2 (2.38 KB, application/xhtml+xml)
2006-07-14 12:33 PDT, aaronr
no flags Details

Description User image Josef Spillner 2006-07-14 10:04:54 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux ppc; en-US; rv: Gecko/20060619 Firefox/
Build Identifier: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv: Gecko/20060619 Firefox/

In the example file, both an input and a select1 are bound to the same (integer) variable. Even though the select1 only contains numbers, selecting any of them moves the state to invalid (as can be seen by red colour due to some CSS). However, entering the same numbers into the input field works ok (and obviously, entering letters there leads to invalid state).

Reproducible: Always

Happens with all recent xforms extensions.
I was smart enough to test this on Minefield too, same result.
Comment 1 User image alexander :surkov 2006-07-14 10:32:39 PDT
Can you attach testcase?
Comment 2 User image alexander :surkov 2006-07-14 10:34:22 PDT
sor(In reply to comment #1)
> Can you attach testcase?

Sorry, I see.
Comment 3 User image alexander :surkov 2006-07-14 10:43:05 PDT
XForms specs says (

Note that the datatype bound to this form control may include a non-enumerated value space, e.g., xsd:string, or a union of a enumeration and a non-enumerated datatype (called an open enumeration).
Comment 4 User image Josef Spillner 2006-07-14 10:51:05 PDT
But in my case, it doesn't have an "open enumeration" (on purpose).

On a related note (separate bug report?) select1 in xforms even allows selection="open" with "closed enumerations" as my one.
Comment 5 User image aaronr 2006-07-14 12:22:06 PDT
The issue here is that we are counting the carriage returns and whitespaces as part of the values.  According to the Schema spec, we shouldn't do that for numerical and string types.  cr and lf should be changed to spaces and then the leading and trailing spaces should be dropped.  So we shouldn't be marking the controls invalid.  HOWEVER, it isn't clear that xforms should modify the values so that they DON'T have the cr's and lf's so your select1 could still show as out-of-range if you just put '10' in the input.

If you want to work around this in your form, you should change:



Comment 6 User image aaronr 2006-07-14 12:33:08 PDT
Created attachment 229275 [details]
testcase 2

should selecting an item from this select1 cause everything to be invalid or not?
Comment 7 User image alexander :surkov 2006-07-15 06:55:59 PDT
(In reply to comment #6)
> Created an attachment (id=229275) [edit]
> testcase 2
> should selecting an item from this select1 cause everything to be invalid or
> not?

I guess everything should have one and the same behaviour like select1 since instance node contains invalid data in accordance with type.
Comment 8 User image David Bolter [:davidb] 2016-02-04 12:22:41 PST
RIP xforms

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