Bugs in the FlexGrid cell editor

Posted by: timmyj on 14 September 2017, 11:21 am EST

  • Posted 14 September 2017, 11:21 am EST

    This one is difficult to reproduce but it affects our app to the extent that we would need to drop wijmo if unresolved.

    The editor drops characters when initiating an edit using the keyboard making multiple keystrokes in quick succession.

    Here’s the scenario:

    • A cell has a value such as “TEST”
    • We select the cell (without activating the editor) then initiate an edit by typing “123” in quick succession using the number pad.
    • The editor is rendered and contains just the characters “13” or “1” however “12” or “123” flash for a fraction of a second before being replaced with “13” or “1”

    I have narrowed the bug down to two lines line in wijmo.grid.ts 5.20151.51

    Line 6164 & 6165:

    [js]

    edt.value = String.fromCharCode(e.charCode);

    edt.setSelectionRange(1, 1);

    [/js]

    This is embedded in a timeout and when line 6164 executes, edt.value == either “12” or “123” and String.fromCharCode(e.charCode) == “1”

    So “12” or “123” are replaced in the editor with “1” and the caret is moved to 1 resulting in either “13” if the third keystroke is inserted after line 6165 executes or “1” if had already been inserted.

    Commenting out lines 6164 & 6165 seems to fix the issue for us but we’re keen for an official fix.

    Additionally there is another bug which is a little easier to reproduce.

    The value inside the editor is overwritten with the original value from the cell if a refresh occurs while editing a cell even if the refresh is supposed to be specific to a single row which isn’t currently being edited.

    In our case, each time a cell edit is complete we send the entire row to a server API for cross reference validation. Once the server responds with the result then we need to do a refresh of that row so that it can be decorated with the appropriate css styles to display validation markers and highlighting etc.

    [js]

    self._grid.refreshCells(true, false, new wijmo.grid.CellRange(row));

    [/js]

    If another cell is being edited when the response is received and subsequent refreshCells call made, the value in the editor is replaced with the original value from the cell.

    When we make a refreshCells call for a single row, why can’t just that row be refreshed instead of the entire grid?

  • Posted 14 September 2017, 11:21 am EST

    Hello,

    1. Unfortunately, I am not able to replicate the issue at my end with the latest version of FlexGrid i.e. 2015v1.63. I would suggest you to test the issue with the latest version which you can download from the following link: http://wijmo.com/products/wijmo-5/

    Hope it helps. In case the issue still persists please share a sample application depicting your issue so that we can replicate and debug the issue further at our end. It would be helpful if you could share a video depicting the steps followed and the issue observed. Please let us know in case you are facing this issue with any specific browser.

    2 We are able to replicate the issue at our end. We are investigating the issue further. We will soon share our observations on the same.

    Thanks,

    Manpreet Kaur

  • Posted 14 September 2017, 11:21 am EST

    Part 2 http://jsfiddle.net/td3sa6oz/

    This simulates rows being sent to a server for validation after they’re edited.

    • Rows are darkened and a loading wheel displayed while they’re validation request is pending
    • Rows are highlighted green if they’re found to be valid
    • Rows are highlighted red if they’re found to be invalid

    To reproduce to problem:

    • Edit any cell and change its value
    • Move selection to a different row
    • While the edited row is still validating, start editing a cell in another row, modify its value and leave the editor open with the modified value
    • When validation is completed on the original row, an attempt is made to refresh just that row in order to remove the loading wheel and display the appropriate highlight colour. This results in the modified value in the active editor being replaced.

    As for part 1:

    It would take me an extensive amount of time to reproduce this in a fiddle so I’ll do what I can to get a screen capture demonstrating the bug.

    It’s pretty obvious looking at the code in wijmo.grid.ts that there is an avenue for error in the following code:

    [js]

    setTimeout(function () {

    var edt = g.activeEditor;

    if (edt && edt.type != ‘checkbox’) {

    edt.value = String.fromCharCode(e.charCode); // FireFox needs this…

    edt.setSelectionRange(1, 1);

    g._edtHdl._keyPress(e); // start auto-complete

    }

    }, 0);

    [/js]

    In the time between when that timeout is set and when its executed, the 2nd and 3rd keystrokes are recognised by the browser and the value of the editor is updated accordingly. The code inside the timeout then executes overwriting the editor’s value with the value of the first keystroke.

    So you enter “123” and you see “123” blink in the editor for a fraction of a second before it changes to “1”

    In my opinion, it’s not difficult to see how there’s a possibility for error there without reproducing it and it’s a bit disappointing that the burden of reproducing it is placed on me before you’ll even acknowledge that it’s a problem

  • Posted 14 September 2017, 11:21 am EST

    Hello,

    We apologize for the inconvenience caused. Unfortunately, we were not able to replicate the first issue reported by you. But as mentioned above we were already able to replicate the second issue. We have escalated it to the development team. We will let you know as soon as we get any information in this regard.

    We went through the code snippet shared by you and it seems to be error prone. However, in order to escalate the issue we would need to reproduce the issue. We would request you to share a screenshot depicting your issue, so that we can escalate the issue further.

    I would like you to know that we were able to reproduce the first issue when the custom editors are used in FlexGrid and this issue has already been escalated to the development team. Could you please confirm in case you are facing this issue when using the custom editors in FlexGrid or by using the default editor of FlexGrid. It would help us to narrow down the issue.

    Thanks,

    Manpreet Kaur

  • Posted 14 September 2017, 11:21 am EST

    This example for part one is using FlexGrid’s default editor without any customisation.

    See attached screen shots of debugging in firefox. The issue is also present in chrome but happens far less frequently.

    • The first shot shows the cell selected before any keys are pressed.
    • The second shot shows the cell and debugger paused inside the timeout immediately after typing “123” in quick succession. You can see in the watch expressions that all 3 keystrokes have been recognised and that the editor value of “23” will be replaced with the string from the first KeyboardEvent’s charCode “1”
    • The third shot shows the end result after the code in the timeout has finished executing.

    One key difference between our app and the examples you provide is that our itemFormatter is quite extensive and adds a lot of different classes & attributes to the cell elements based on a variety of different conditions.

    The current workaround we have in place seems to work albeit with the crude inclusion of browser specific code but as I said previously, an official fix would be preferred.

    Current workaround - Replace lines 6160-6169 of wijmo.grid.ts as follows:

    [js]

    if (!g.columns[g.editRange.col].mask) {

    var edt = g.activeEditor;

    if (navigator.userAgent.toLowerCase().indexOf(‘firefox’) > -1) {

    edt.value = String.fromCharCode(e.charCode);

    edt.setSelectionRange(1, 1);

    }

    setTimeout(function () {

    if (edt && edt.type != ‘checkbox’) {

    g._edtHdl._keyPress(e); // start auto-complete

    }

    }, 0);

    }

    [/js]

  • Posted 14 September 2017, 11:21 am EST

    Please note the forum displays the attachments in the wrong order.

    The correct order is:

    Attachment 3 (01)

    Attachment 1 (02)

    Attachment 2 (03)

  • Posted 14 September 2017, 11:21 am EST

    Hello,

    Thank you for providing the additional information. However, I could observe that the fiddle provided by you for part two uses 2014v2 version of Wijmo5. I would suggest you to test the issue even with the latest version i.e. 2015v1.63, to see if it helps. You can download the latest version from the following link: http://wijmo.com/products/wijmo-5/.

    Please let us know in case the issue still persists at your end.

    Thanks,

    Manpreet Kaur

  • Posted 14 September 2017, 11:21 am EST

    We’re on version 5.20151.51 currently but I’ll be moving to the latest shortly.

    I forked one of the your official demo fiddles to create the example hence the older version however both issues are definitely present in 5.20151.51

    I’ll test with latest asap.

  • Posted 14 September 2017, 11:21 am EST

    Hello,

    As per the development team, the grid does not provide a method for refreshing individual cells. The refreshCells method is mostly used internally.

    Here’s a possible way to accomplish your requirement:

    [js]

    grid.rowEditEnded.addHandler(

    function (s, e) {

    var record = s.rows[e.row].dataItem;

    record.setTransient(true);

    //Simulate server validation/save

    setTimeout(function () {

    record.setValid(Math.round(Math.random()));

    record.setTransient(false);

    // if editing, save editor state
    var edt = s.activeEditor,
        start = edt ? edt.selectionStart : 0,
        end = edt ? edt.selectionEnd : 0;
    
    // refresh the grid (all cells)
    s.refresh();
    
    // restore editor state
    if (edt) {
      s.startEditing();
      s.activeEditor.setSelectionRange(start, end);
    }
    

    }, 5000);

    [/js]

    Kindly refer to the attached HTML Page which implements the same. Hope it helps.

    Thanks,

    Manpreet Kaur

    2015/12/RefreshCells_Working.html

  • Posted 14 September 2017, 11:21 am EST

    Hello manpreet.kaur,

    My team and I can also duplicate issue number 1 above that Timmy J posted about. This is a huge issue for us and our users.

    Our users manually enter values into the grid and when the grid is consistently missing characters this causes a severe slow down in productivity for them. We are using the Angular grid.

  • Posted 14 September 2017, 11:21 am EST

    +1

    We’ve noticed that using many cell templates also contributes to this problem, even in non-IE modern browsers (Chrome, etc) which usually don’t suffer from performance problems like IE does.

  • Posted 14 September 2017, 11:21 am EST

    Hello JessO/Mendeza,

    We are unable to replicate issue #1 regarding losing character with quick editing with the latest build 5.20163.259 which can be downloaded from here

    Please refer to the following demo sample http://demos.wijmo.com/5/angular/flexgridintro/flexgridintro/ .

    If issue persists, please provide a sample depicting your issue so that we can assist you accordingly.

    Thanks ,

    Manish Kumar Gupta

  • Posted 14 August 2018, 8:17 am EST

    Any update on this?

    I’ve got same issue: https://www.screencast.com/t/FMomD6ikzdN

    (0:16, 0:22)

    Wijmo version is “5.20172.334”

    I was not able to reproduce it in stackblitz.

    One suggestion is that our page is pretty heavy (few grids and charts) and it is works slower that simple stackblitz examples.

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels