Wijmo FlexGrid hit tests sometimes incorrectly point to the right element

Posted by: software on 6 November 2022, 2:15 pm EST

  • Posted 6 November 2022, 2:15 pm EST

    We have recently noticed an issue with event listeners for the Wijmo FlexGrid and the hitTest method on FlexGrids. When using a simple event listener on the native element of the grid, such as ‘mouseover’, and passing the resulting MouseEvent through to Wijmo’s ‘hitTest’ method we can observe that there are times when the element we can see we are mousing over is not the element that the hit test says we are mousing over.

    Additionally even when we repeatedly move between rows on the grid the value will not change, leaving us physically hovering row 2 when the hit test thinks that we’re on row 1.

    This problem seems especially exacerbated when working with grouped column headers or column groups in general. When moving between the rows in the column headers collection for grouped columns often we will end up off by one on which column header we are pointing at.

    I have created a demo at the following stackblitz url for you to look at, and I will also attach a video demonstration of the issue. You can see the problem explained in the attached video at roughly 14 seconds in, where I am moving between cells on different rows but the row number does not update.

    hit test out of date.zip

    [Stackblitz link]

    This is can cause issues as we have logic that relies on which cell the mouse is hovering that can sometimes end up displaying incorrectly due to the hit test pointing at the wrong element (and having invalid row/col coordinates).

    We am happy to provide any more information you might need.

  • Posted 6 November 2022, 2:17 pm EST

    The title is incorrect, it should say “Wijmo FlexGrid hit tests sometimes incorrectly point to the wrong element”.

    Sorry for any confusion.

  • Posted 6 November 2022, 10:19 pm EST


    We have escalated this issue to the dev team for further investigation, with internal tracking id WJM-25291. We will update you as soon as we have an update from the dev team. Meanwhile, you can use the ‘mousemove’ event instead of ‘mouseover’ event, to avoid this issue.


  • Posted 10 November 2022, 3:04 pm EST

    Mousemove does help alleviate this issue, but it does cause a new event to fire for every single small movement of the mouse. You can see how this might become inefficient if the event listener you have contains some complex functionality/calculations.

    Thanks for the suggestion and for escalating it to the dev team.

Need extra support?

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

Learn More

Forum Channels