[7.0.0.157 Classic] Ext.form.field.Date 'select' event fires without value change

[fabricio.object]

The 'select' event keeps firing from an Ext.form.field.Date component even if the date does not change.

This can be reproduced in the following fiddle:



The fiddle should be autodescriptive to reproduce the issue. It also suggests a fix.

The problem triggers because a change introduced in Ext JS 6.7.0 relied ensuring the value didn't change via the Ext.form.field.Field.didValueChange() "private" method. The Date field would require specialized test to ensure two date objects are effectively the same -- for instance, ensuring both current and new values are the same type.

[mitchellsimoens]

I think I'd actually would prefer to fix this in Ext.picker.Date so that it doesn't tell the field that something was changed and it tracks a last value. Although looking at the date picker, there are multiple areas where it fires the select event and sets a value, that could be cleaned up so there is only one place to do such.

[fabricio.object]

What about "it triggers 'select' by displaying the picker"? That's because the field lost focus, I suppose.

If you tab in, then tab out, or click (to focus) then click elsewhere, is it the 'select' event expected to be triggered?

Down to Ext JS 6.6.0 (or 6.5.0?) the event was only triggered when selection happened from the picker. The code introducing the change as of 6.7.0 (thus 7.0.0, unchanged), semantically "select on setValue" has a clear attempt in the code not to trigger select when the value is not changed from its previous one. The test is simply always "true" (meaning they are different) if the provided value is a string.

For instance, if you add a javascript window.alert() to the select event, you could get stuck in the alert, as the dialog will take out focus (and stop script execution), then move focus back (and then realize the focus was taken by the blocking alert()), then a loop happens. Loop does not happen deterministically, there should be a "timing" or something like it.

I just think that, -if- the select is to trigger on blur, or rather, in every setValue() call, then that test calling [b]didValueChange()[/var] should be removed from the code.

[mitchellsimoens]

The reason I say I'd rather fix it in the picker is because a "select" event is when you select a date from the picker. Fix that event in the picker so when it bubbles up to the field it should be normalized and "fixed". The "change" event on the field is more the catch all event where values can be set from selecting a date in the picker or programmatically or by typing and using it instead of the select event does only fire for different dates.

[fabricio.object]

This makes sense, but the guys in there now just changed (in 6.7.0) the semantics of the select event so it fires whenever, like the change one, not only when something is "picked" from the dropdown. It was so much in purpose that the updated the information in the docs accordingly.

Just compare the documentation page between 6.6.0 and 6.7.0.
- 6.7.0 docs on Ext.form.field.Date.select event
- 6.6.0 docs on Ext.form.field.Date.select event

It may still be time for a 7.1 version to revert this change if it was done by mistake. Although I'd consider that a breaking change, it was just recently introduced... so...

[mitchellsimoens]

Yea, I agree and it's a change of behavior that maybe wasn't considered. I'll see if I can get something logged for this.

[mitchellsimoens]

fyi, they assigned EXTJS-28155 to this.

[mcouillard]

We ran into this, too, after upgrading from 6.6 to 6.7. Feels like 2 bugs:
- select fired on picker open (aka blur, I guess)
- select fired when component has a value set within its initial config

Root of both could be degraded change detection in 6.7. Doesn't seem to be comparing like values anymore (in one case we saw it compare a Date to a String).