Hi,
there is a really scary problem in 5.0p and 5.1d (not in 4.1p).
At least the following browsers are affected
* IE 11
* Firefox 34.0 on Windows
* Chromium Version 39.0.2171.65 Ubuntu 14.04 (64-bit)
I tried this with the latest nightlies (2015-01-10). A test case reproducing the problem is attached.
The core problem is that when setting a ComboBoxItem back to empty, the ComboBoxItem SILENTLY discards that change. Instead it SILENTLY resets to the previous value!
To make things worse, this only happens when there is
a) another ComboBoxItem in the DynamicForm, OR
b) another IntegerItem in the DynamicForm
The attached test case shows this.
Steps to reproduce:
* DataSourceA as a source for the DynamicForm with
- DataSourceIntegerField for ComboBoxItem-FormItem
- DataSourceIntegerField for a IntegerItem-FormItem
* DataSourceB as a optionDataSource with
- DataSourceIntegerField as valueField for the ComboBoxItem
- DataSourceTextField as displayField for the ComboBoxItem
- Mock a few records into the DataSource to have selectable values in the ComboBoxItem
* DynamicForm with
- Attached to DataSourceA
- ComboBoxItem with DataSourceB as optionDataSource and valueField and displayField set accordingly
- Attached to ValuesManager
* ValuesManager attached to DataSourceA and DynamicForm
* Button
- valuesManager.validate()
- GWT.log(valuesManager.getChangedValues().toString());
- valuesManager.saveData();
* Start app
* Select a value from the ComboBoxItem
* Enter a value in the IntegerItem (1122)
* Hit Save Button
- Note that getChangedValues logs that both attributes got changed
* Empty the ComboBoxItem (by selecting the text and hitting backspace, or any other way)
* Hit Save Button
- valuesManager.getChangedValues().size() is 0!!!!
The valuesManager.validate() triggers the problem, too, but it is not necessary though: The problem also occurrs without validate() and with saveData() only. The field of the ComboBoxItem is rolled back to its original value in the record on saveData(). Using valuesManager.getChangedValues() after valuesManager.validate() is an easy way to show and test the problem. But you can do without it. Using setAddUnknownValues and setAllowEmptyValues on the ComboBoxItem does not change the false behaviour.
The problem is really hard to discover: It DOES NOT occur, if you have only a single ComboBoxItem and no other IntegerItem ot ComboBoxItem in the DynamicForm! You can have a TextItem, a RichTextItem or a DateItem in the form, and it works as expected. Add another ComboBoxItem or an IntegerItem and the bug shows up.
Apart from us being affected I consider this a really evil problem, since it is so hard to notice! And since it is there I assume no one has noticed it since. The thought of how many data changes have been lost since it is there without any user noticing it scares me.
We have just finished a new version of our application and this week the User Acceptance Test starts. We were using 4.1p until shortly before christmas we discovered a bug there (we will provide a bug report for that, too, soon). This bug does not occur in 5.0p which is why we migrated to 5.0p then and noticed no problems so far, until just yesterday night we discovered this.
It would be really helpful for us if you could fix that immediately.
Remarks regarding the test case:
The GwtRpcDataSource is just a dummy for clientOnlyDataSource, which is the implemented in the BugReportDataSource. The whole project serves as test case project for us, which is the reason why there is a Demo-interface.
I added a little bit of investigation of when the bug was introduced:
* 5.0p nightly 2014-09-14 does not show the problem
* 5.0p nightly 2014-11-30 DOES show the problem
Let me add that we are long time users of SmartGwt and enjoy it pretty much. I hope that you can locate the source of that bug.
Regards,
Andre
there is a really scary problem in 5.0p and 5.1d (not in 4.1p).
At least the following browsers are affected
* IE 11
* Firefox 34.0 on Windows
* Chromium Version 39.0.2171.65 Ubuntu 14.04 (64-bit)
I tried this with the latest nightlies (2015-01-10). A test case reproducing the problem is attached.
The core problem is that when setting a ComboBoxItem back to empty, the ComboBoxItem SILENTLY discards that change. Instead it SILENTLY resets to the previous value!
To make things worse, this only happens when there is
a) another ComboBoxItem in the DynamicForm, OR
b) another IntegerItem in the DynamicForm
The attached test case shows this.
Steps to reproduce:
* DataSourceA as a source for the DynamicForm with
- DataSourceIntegerField for ComboBoxItem-FormItem
- DataSourceIntegerField for a IntegerItem-FormItem
* DataSourceB as a optionDataSource with
- DataSourceIntegerField as valueField for the ComboBoxItem
- DataSourceTextField as displayField for the ComboBoxItem
- Mock a few records into the DataSource to have selectable values in the ComboBoxItem
* DynamicForm with
- Attached to DataSourceA
- ComboBoxItem with DataSourceB as optionDataSource and valueField and displayField set accordingly
- Attached to ValuesManager
* ValuesManager attached to DataSourceA and DynamicForm
* Button
- valuesManager.validate()
- GWT.log(valuesManager.getChangedValues().toString());
- valuesManager.saveData();
* Start app
* Select a value from the ComboBoxItem
* Enter a value in the IntegerItem (1122)
* Hit Save Button
- Note that getChangedValues logs that both attributes got changed
* Empty the ComboBoxItem (by selecting the text and hitting backspace, or any other way)
* Hit Save Button
- valuesManager.getChangedValues().size() is 0!!!!
The valuesManager.validate() triggers the problem, too, but it is not necessary though: The problem also occurrs without validate() and with saveData() only. The field of the ComboBoxItem is rolled back to its original value in the record on saveData(). Using valuesManager.getChangedValues() after valuesManager.validate() is an easy way to show and test the problem. But you can do without it. Using setAddUnknownValues and setAllowEmptyValues on the ComboBoxItem does not change the false behaviour.
The problem is really hard to discover: It DOES NOT occur, if you have only a single ComboBoxItem and no other IntegerItem ot ComboBoxItem in the DynamicForm! You can have a TextItem, a RichTextItem or a DateItem in the form, and it works as expected. Add another ComboBoxItem or an IntegerItem and the bug shows up.
Apart from us being affected I consider this a really evil problem, since it is so hard to notice! And since it is there I assume no one has noticed it since. The thought of how many data changes have been lost since it is there without any user noticing it scares me.
We have just finished a new version of our application and this week the User Acceptance Test starts. We were using 4.1p until shortly before christmas we discovered a bug there (we will provide a bug report for that, too, soon). This bug does not occur in 5.0p which is why we migrated to 5.0p then and noticed no problems so far, until just yesterday night we discovered this.
It would be really helpful for us if you could fix that immediately.
Remarks regarding the test case:
The GwtRpcDataSource is just a dummy for clientOnlyDataSource, which is the implemented in the BugReportDataSource. The whole project serves as test case project for us, which is the reason why there is a Demo-interface.
I added a little bit of investigation of when the bug was introduced:
* 5.0p nightly 2014-09-14 does not show the problem
* 5.0p nightly 2014-11-30 DOES show the problem
Let me add that we are long time users of SmartGwt and enjoy it pretty much. I hope that you can locate the source of that bug.
Regards,
Andre
Comment