Form has changed values for unmodified record.

[stonebranch3]

Isomorphic,

There appears to be an issue with forms reporting changed values even though the record has not been modified . It appears to be related to the field value being an empty string.

I only see this issue with IE.

I'm using IE11 and SNAPSHOT_v10.1d_2015-08-06/Pro Deployment (built 2015-08-06).

I've modified the following showcase sample to illustrate the issue.

http://www.smartclient.com/smartgwt/..._form_category

I changed the RecordClickHandler to log the changed values since I want to detect if there are unsaved changes on the form before selecting the new record.

listGrid.addRecordClickHandler(new RecordClickHandler() {
            public void onRecordClick(RecordClickEvent event) {
                Map changedValues = form.getChangedValues();
                SC.logInfo("Changed Values: " + changedValues);
                form.reset();
                form.editSelectedData(listGrid);
            }
        });

I also changed the description for one of the records to an empty string.

new ItemRecord(2, "Glue Pelikan Roll-fix Refill Permanent #955", "1089400", "", "Rollfix Glue", "Ea", 3.73, null, null)

As you select different records in the list (without making any changes to the form), you'll eventually see the description field get logged as a changed value.

16:03:44.988:INFO:Log:initialized
16:03:45.326:INFO:Log:isc.Page is loaded
16:03:53.281:pointerup5:INFO:Log:Changed Values: {}
16:03:54.976:pointerup4:INFO:Log:Changed Values: {}
16:04:01.384:pointerup0:INFO:Log:Changed Values: {}
16:04:06.880:pointerup4:INFO:Log:Changed Values: {description=}
16:04:10.144:pointerup7:INFO:Log:Changed Values: {description=}
16:04:11.296:pointerup0:INFO:Log:Changed Values: {}
16:04:12.008:pointerup1:INFO:Log:Changed Values: {}
16:04:12.799:pointerup3:INFO:Log:Changed Values: {}
16:04:13.424:pointerup5:INFO:Log:Changed Values: {description=}

Thanks.

[Isomorphic]

Just a note that we've reproduced the problem and we're trying to figure out what's going on. This may be some kind of weird GWT bug with IE.

[stonebranch3]

OK, thanks for the update.

[Isomorphic]

We've confirmed that this only happens when GWT is involved, so it could turn out to be a nasty bug with confusion about whether something is a String, similar to the String serialization / String.toString() bug from GWT pre-2.5 (see FAQ).

This one could be a while.

[stonebranch3]

Thanks for the heads up.

I'm using GWT 2.6.1. Were you able to reproduce this with GWT 2.7.0?

[Isomorphic]

We've applied a fix for SGWT 5.0p and newer that should resolve this issue. It should be in the nightly builds dated 2015-08-29.

[stonebranch3]

Isomorphic,

This issue is resolved for the modified Showcase sample using the Aug 30 build, however, I still see the issue with my application. My application is using a remote datasource (DMI) instead. Could this explain the fix not working?

Thanks

[Isomorphic]

We can't really guess at why DMI per se would be responsible for a difference in behavior, but clearly you have something different in your app case than in the test case you showed us.
Most likely it's a difference in the data structure being passed to your ListGrid.

Probably the best way to proceed would be to get us a simple-as-possible reproducible case of the new problem so we can reproduce it on our end and see what the difference is.

This would probably be as simple as:

- A very simple dataSource with a DMI operation for fetch
- Have the server code for this operation simply build and return a simple java object which matches the structure of the record in your real app
- An entry point class which builds minimal UI bound to this dataSource -- at a guess a ListGrid and a DynamicForm, with a recordClick handler on the grid to start editing the record in the form.

You can show us these 3 pieces of code (Entry point class, dataSource definition and the DMI server method) and we should be able to reproduce the issue on our end.

Regards
Isomorphic Software

[stonebranch3]

Isomorphic,

Thanks for the quick reply.

Here is a simple DMI case that reproduces the problem.

Entry Point:

    public void onModuleLoad() {
        VLayout layout = new VLayout(15);
        layout.setWidth100();
        layout.setHeight100();

        final DataSource dataSource = DataSource.getDataSource("itemSupply");

        final ValuesManager manager = new ValuesManager();
        manager.setDataSource(dataSource);
        final DynamicForm form = new DynamicForm();
        form.setIsGroup(true);
        form.setGroupTitle("Details");
        form.setNumCols(4);
        manager.addMember(form);

        final ListGrid listGrid = new ListGrid();
        listGrid.setWidth100();
        listGrid.setHeight(200);
        listGrid.setDataFetchMode(FetchMode.LOCAL);
        listGrid.setDataSource(dataSource);
        listGrid.setAutoFetchData(true);
        listGrid.addRecordClickHandler(new RecordClickHandler() {
            public void onRecordClick(RecordClickEvent event) {
                ListGridRecord record = listGrid.getSelectedRecord();
                Map changedValues = manager.getChangedValues();
                if (changedValues != null && !changedValues.isEmpty()) {
                    SC.warn("Changed Values: " + changedValues);
                }
                manager.resetValues();
                manager.editRecord(record);
            }
        });

        layout.addMember(listGrid);
        layout.addMember(form);

        layout.draw();
    }

DataSource Definition:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<DataSource xmlns:fmt="WEB-INF/" ID="itemSupply" serverType="generic">
    <fields>
        <field name="itemId" type="text" primaryKey="true" hidden="true"/>
        <field name="itemName" type="text" length="128" required="true">
            <title>Item Name</title>
        </field>
        <field name="description" type="text" length="2000">
            <title>Description</title>
        </field>
	</fields>
	<serverObject lookupStyle="new" className="com.sandbox.server.ItemSupplyDS"/>
</DataSource>

DMI Method:

    public DSResponse fetch(final DSRequest req) {
        DSResponse resp = new DSResponse();
        resp.setData(getData());

        return resp;
    }

    private List<Map<String, Object>> getData() {
        List<Map<String, Object>> records = new ArrayList<>();

        Map<String, Object> record = new HashMap<>();
        record.put("itemID", 1);
        record.put("itemName", "Item 1");
        record.put("description", "Item Description");
        records.add(record);

        record = new HashMap<>();
        record.put("itemID", 2);
        record.put("itemName", "Item 2");
        record.put("description", "");
        records.add(record);

        record = new HashMap<>();
        record.put("itemID", 3);
        record.put("itemName", "Item 3");
        record.put("description", null);
        records.add(record);

        return records;
    }

[Isomorphic]

Just a note to say we see the problem and are looking into it. We'll follow up when we have more information for you.

Regards
Isomorphic Software

[Isomorphic]

This issue is now resolved.
Please try the next nightly build dated Sep 9 or above (5.0p / 5.1d branches)

Regards
Isomorphic Software

[stonebranch3]

I upgraded to the Sep 9 build (5.1d) and the issue is resolved. Thanks!

[stonebranch3]

Hi Isomorphic,

I found another case where the form is detecting changes even though the record has not been modified.

The problem looks to be due to the value containing a carriage return character (\r). You can use the following DMI method along with the Entry Point and DataSource above to reproduce the issue.

DMI Method:

     public DSResponse fetch(final DSRequest req) {
          DSResponse resp = new DSResponse();
          resp.setData(getTestData());
   
          return resp;
      }
   
      private List<Map<String, Object>> getTestData() {
          List<Map<String, Object>> records = new ArrayList<>();
   
          Map<String, Object> record = new HashMap<>();
          record.put("itemID", 1);
          record.put("itemName", "Item 1");
          record.put("description", "Item 1 Description");
          records.add(record);
   
          record = new HashMap<>();
          record.put("itemID", 2);
          record.put("itemName", "Item 2");
          record.put("description", "Item 2 Description");
          records.add(record);
   
          record = new HashMap<>();
          record.put("itemID", 3);
          record.put("itemName", "Item 3");
          record.put("description", "Item 3 Description\r\n");
          records.add(record);
   
          return records;
      }

Here are the steps to reproduce the issue:

1. Select the "Item 3" record in the list grid.
2. Click in the Description field on the form.
3. Select a different record in the list grid. You should get a popup showing that the Description field has changed.

I am able to reproduce this using Firefox, Chrome and IE. I'm using SmartClient Version: v10.1p_2016-01-03/Pro Deployment (built 2016-01-03).

Thanks

[Isomorphic]

There's a native HTML / JS behavior whereby

<textarea>

elements deal in line feed (\n) characters rather than carriage returns by default.

HTML5 mandates that a textarea's "API value" (which is used for the value property) be normalized by first replacing every "\r\n" with "\n" and then every remaining "\r" with "\n":
http://www.w3.org/TR/html5/forms.htm...area-api-value

What's happening in this case is that we are natively setting the value on the textarea element in the DOM, and then reading it back and the \r\n has been converted into \n automatically (which we detect as a change).

One question - is it actually a requirement in your app to deal with "\r\n" line ends? If not, the quickest solution here might be to use unix-style line feeds (\n) in your app data.

Regards
Isomorphic Software

[stonebranch3]

Thanks for the explanation.

It's not a requirement to deal with "\r\n" line ends so we can use unix-style line feeds going forward. The form will still detect a change for existing app data, however, this can be resolved by saving the record.