An 'xforms-valid' handler that increments is repeatedly called

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open the attached form
2. Click into input
3. Enter random characters
4. Click out of the control
5. Task manager shows browser using 100% memory and xf:output doesn't stop
incrementing.

What is the expected output? What do you see instead?

I expect the xf:output to be incremented by 1 after point four above.

Please use labels to indicate the version, operating system and browser
that you are using. Also, add some text below to provide additional
information.

I noticed the described behaviour in IE7 and FF3.5.3 on Windows XP SP3.

Original issue reported on code.google.com by alex.san...@gtempaccount.com on 9 Oct 2009 at 3:57

Attachments:

• infinite.html

[GoogleCodeExporter]

Hi Al,

I'm not completely sure this is a bug -- would you mind doing a bit more 
research?

The reason I say this, is because you have a handler registered on the 
'xforms-valid' 
event being received on the input control; I have a feeling that 'xforms-valid' 
is fired 
every time the data changes (provided it's valid, of course), not just on the 
transition 
from invalid to valid. So if you do an increment in the handler, you'll just 
cause the 
'xforms-valid' to be dispatched all over again.

I might be wrong on this of course, which is why I think you'll need to go back 
to the 
spec and double-check.

Original comment by mark.bir...@gmail.com on 16 Oct 2009 at 10:21

• Changed title: An 'xforms-valid' handler that increments is repeatedly called

[GoogleCodeExporter]

I do think that this is a bug. Looking at the XF1.1 specification at the 'Event
sequencing' section (http://www.w3.org/TR/xforms11/#rpm-event-sequences), it 
says in
4.6.1, amongst other things:

* When the form control is interactively changed and does not have the
incremental="true" setting, no events are required to be dispatched, and thus no
order is defined.

Which is fine but then, later:

* When focus changes from the form control and the value has changed, then, 
after the
new value is placed into the bound instance node, the event sequence is as 
described
at 4.6.7 Sequence: Value Change.

I'd take this to mean, in relation to my bug description and the form I 
attached,
after step 4, the xforms-valid event should occur just once (the input control 
in the
form isn't @incremental="true").

Also, I modified the form (attached) to test it with Ubiquity formsPlayer and 
the
results are as I expected, the xforms-valid event only happens once, on 
navigating
away from the control.

Original comment by alex.san...@gtempaccount.com on 16 Oct 2009 at 11:21

Attachments:

• infinite-fp.html

[GoogleCodeExporter]

I agree with Mark. The relevant section of the spec is 4.4.4 ("The xforms-valid 
Event"), it states:

"Dispatched in response to: an instance data node either changing and being or 
becoming valid."

Admittedly it could be better worded, but I think that the "being or becoming" 
part 
implies that Ubiquity XForms is demonstrating compliant behaviour here. So I 
think 
the bug is on formsPlayer's side (not that it matters much to me, either way 
I'd have 
to fix it somewhere). :)

I assume that the actual use case you have is somewhat different to the one in 
the 
sample form you've attached. Is there a way for you to use a separate instance 
datum, 
so as to prevent the xforms-valid event from invoking itself?

Original comment by phil.boo...@gtempaccount.com on 16 Oct 2009 at 4:07

[GoogleCodeExporter]

Am marking this issue as invalid, as per the preceding discussion. I'm not sure 
if 
this applies to the actual use-case, but it may be worth the OP investigating 
the use 
of an extra instance datum to operate as a boolean flag, with the intention of 
only 
acting upon the first xforms-valid of each set, e.g.:

<xf:action ev:event="xforms-valid" if="/data/isValid = 'false'">
    <xf:setvalue ref="/data/isValid" value="'true'" />
    ...
</xf:action>
<xf:action ev:event="xforms-invalid" if="/data/isValid = 'true'">
    <xf:setvalue ref="/data/isValid" value="'false'" />
    ...
</xf:action>

Original comment by phil.boo...@gtempaccount.com on 19 Oct 2009 at 1:46

• Changed state: Invalid