Thank you for reporting this bug. We will make it our priority to review this report.
Touch Premium Member
Form Field Validations mess with focus event using Model.set()
Mac OSX 10.6
I'll try my best to explain.
How to reproduce the bug:
*Create a formPanel and a store to hold a record for the panel.
*Make some of the fields in the form panel numberfields and datefields (fields that require validation) in addition to textfields.
*Attach 'blur' and 'focus' event handlers to each formPanel field, and have them log what the currently blurred/focused fields are.
*In the blur listener, have the record locally save the currently focused field using Model.set() for the new value.
*Now, edit a field and tab to the next field
What you will notice is that the focus listener will log a different field than what is expected when tabbing out of datefields and numberfields.
You will also notice that this doesn't happen for normal text fields (probably because they don't require validation).
However, if you use Ext.defer() on the Model.set() portion of the blur's listener, for 100 ms, the focus listener will show the expected field.
It looks like the validation from the previous field's blur isn't finishing in time for the correct field to trigger the next field's focus handler.
I think that as Ext's 'focus' event fires, the blur handler for the previous field is in the middle of setting and validating the field. So the focus event catches the blur's set method with its pants down, so to speak, and logs a different field (the first field in my panel in my case).
Now, I think this qualifies for a bug, because Ext's focus event should not fire until Ext is finished validating the field with Model.set(). Since set() has no callback, there is no way no know when that validation stuff is done.
Can someone smart test this and back me up here? I'm not great at providing concrete examples.
Before we go too far and try and manufacture a test case to pass up have you tried the same scenario with 4.2 (or even 4.2.1 Beta)?