2

We have encountered a subtle issue with ExtJS grid. It is quite regular grid with standard 'cell editor' plugin and two editable columns (having at least two is important). Once an editable cell is submitted, the store backing the grid gets reloaded. However grid reload takes place in a subsequent time slot because it's a part of asynchrouous task completion.

All this works well unless the user submits editable cell with the Tab key rather than with Enter. Tab makes second column's cell editor visible and shifts input focus there. After that the store reloads, or at least I believe it happens afterwards.

At first glance nothing bad happens to the UI, it continues working as usual. However after some time an attempt to hover the mouse over any element to which a tooltip is attached causes crash and console gets flooded with errors.

We've been able to establish immediate reason of this: garbage collection cycle that follows grid reload treats the input field belonging to the second column's editor as garbage. As a result Ext.Element instance wrapping this field has its dom property erased. By itself it's seemingly not an issue. However, for some reason, when it comes to show a tooltip, the system tries to get its hands on the Element that was previously garbage collected. Strangely enough, that element has nothing to do with tooltips.

In order to reproduce this open the fiddle and then

  • Double-click any cell in the first column to make it editable
  • Type any value
  • Press Tab on the keyboard
  • Wait 30 seconds
  • Move and hover the mouse over the grid cells to view tooltips

It does not need to be a grid tooltip, the bug equally occurs even if the mouse hovering over any unrelated UI element with tooltips.

So the question is: how can it be that garbage-collected element is reused, and how to correct this?

AlexPs801012
  • 75
  • 7
  • 2
    I can't tell you hot to fix it, but it's happening because ExtJS caches component queries for performance reasons. Components are meant to be removed from that cache when destroyed - if they aren't, the cache breaks because it doesn't check if a component is destroyed before dereferencing it. It mostly happens when floated components aren't cleaned up properly. – Robert Watkins Feb 03 '20 at 22:02
  • 1
    In this particular case, it appears that reloading the store on editing is the culprit; events that are fired during processing destroys the associated grid rows, along with their input cells - but your tooltip is still hovering over it, and it doesn't know the input cell is destroyed. You may want to try destroying the tip and recreating it. – Robert Watkins Feb 03 '20 at 22:23
  • @RobertWatkins We came to the same conclusion regarding the cache, indeed it seems that cached item is garbage-collected and still remains in the cache. – Mooh Feb 04 '20 at 10:33
  • However it is not because the tooltip is tied to a vanished editor field. All the operations but last needed to reproduce this can be carried out without touching the mouse, hence without letting ExtJS show or even create any tooltips. At the final step, after 30 seconds of waiting, it is enough to make it show *any* tooltip, even if it's tied to a completely unrelated widget such as toolbar button. – Mooh Feb 04 '20 at 10:35
  • 1
    In this [example](https://fiddle.sencha.com/#fiddle/33ae) I added a simple tooltip button on the grid toolbar to clearly demonstrate this problem. – AlexPs801012 Feb 04 '20 at 17:33
  • 1
    @Mooh - it's the inputfield that's been cached, not the tooltip. It's just that using the tooltip will trigger a query that hits the problem. The underlying bug is that the input field is not cleaned up properly when the rows are destroyed and recreated. – Robert Watkins Feb 05 '20 at 03:07

0 Answers0