Data not displayed in grid if it contains \u2028 character

[martintaal]

When a databound grid fetches data from server and it contains \u2028 or \u2029 characters no data is displayed at all and a "The server failed to return a formatted response at all." warning message is displayed instead.

Tested in Feature Explorer [1] with isc.version "v11.1p_2017-09-05/AllModules Development Only".

Add the following code to javascript tab:

if (!isc.RPCManager.performTransactionReplyOrig) isc.RPCManager.performTransactionReplyOrig=isc.RPCManager.performTransactionReply

isc.RPCManager.performTransactionReply = function (transactionNum, results, wd) {
var r = results.responseText
// emulating a reponse including \u2028 character
if (r && isc.isA.String(r) && r.indexOf('United States') !== -1) {
console.log(results.response == results.responseText, arguments)
r = r.replace('United States','Modified:United \u2028 States')
Object.defineProperty(results, 'responseText', {
writable: true
})
Object.defineProperty(results, 'response', {
writable: true
})

results.responseText = r
results.response = r
}

return RPCManager.performTransactionReplyOrig(transactionNum, results, wd)
}

and click on "Fetch code:US" button -> no data is displayed in grid.

These special characters are not valid in JavaScript Strings (though they are in JSON), so they should be escaped in client side before trying to evaluate the response.


[1] https://www.smartclient.com/smartcli...crease=0&dhc=1

[Blama]

Hi Isomorphic,

perhaps this is related to this old and fixed bug.

Best regards
Blama

[Isomorphic]

As noted by Blama, these special characters are escaped by the server. Your test case is client-only and is currently expected to fail. What type of DataSource are you using? What server connection method are you using (SC native, REST, etc.)?

[martintaal]

Hi,

We're using a external REST server which does not escape those characters.

Escaping them in server side is not a good option for us, wouldn't make sense to do in client-side?

[Isomorphic]

Try setting useStrictJSON. By default, we allow the more efficient, more flexible full JavaScript syntax to be used, but if this particular server relies on strict JSON encoding and doesn't need anything other than the standard JSON format, useStrictJSON will use a different parser than should handle these special unicode characters.