[2.7] Lost responsive after destroy recreate

[frlinw]

If some options have changed, I destroy the chart then create a new one.

if (chart) chart.destroy()
chart = new Chart(...)

Since 2.7, the div which handle resize detection is removed but is not re-created.
No problem with the iframe in 2.6

[simonbrunel]

Duplicates #4630 but haven't been able to reproduce it. @frlinw can you share your project and/or build a jsfiddle that show this issue?

[frlinw]

@simonbrunel your jsfiddle reproduce the issue perfectly
Initial :

After click on recreate :

[simonbrunel]

The fiddle works for me in Firefox 55. What browser and version are you using to get this issue? any console errors / warnings?

[frlinw]

You are right, it's ok on firefox. I'm using Chrome lastest (60)
Nothing in the console

[simonbrunel]

I can reproduce it using Chrome, not sure what workaround you can use right now. I guess that you have good reason to re-create the chart everytime instead of calling chart.update() after modifying chart.options.

[frlinw]

I already switched to chart.update() during the night so the issue is solved for me. Take your time to fix it ;)

[etimberg]

@simonbrunel @frlinw I debugged through this a bit. Here's what I've got so far:

If I add a breakpoint to line 258 of platform.dom.js then everything works fine in Chrome. If I remove it, then this bug is observed.

In the case where no breakpoint is added, the callbacks on line 261 and 269 are never called.

Interestingly if I add a breakpoint in removeResizeListener and step through it then it also works as expected. My hunch is that something gets queued up to remove the old node and then somehow either prevents the new node from being added, or removes it immediately after it is added.

[daniele-orlando]

Similar issue here. 2.7 is no more responsive.

[frlinw]

@etimberg just for curiosity, what if you put these lines in a setTimeout( ... , 0) ?

[simonbrunel]

On chart destroy, the chartjs-render-monitor class is removed from the canvas node, then, in your case, added back immediately on create. Chrome might decide to optimize the node class changes and prevent the animation to re-execute, so we are not notified on animationstart.

Could be solved by:

• forcing a reflow before adding the class on create (or after removing the class on destroy)
• detecting that the node is visible when creating the chart (and manually call handlers)

I will investigate the second solution first.

@frlinw I think the setTimeout will work since it will re-add the class at the next animation frame

[simonbrunel]

@daniele-orlando @frlinw can you guys please verify that #4774 correctly fix this issue?

[andig]

I already switched to chart.update() during the night so the issue is solved for me.

Same for me.

[mwaldstein]

I had a very similar issue with chrome not being responsive while it was in firefox - I thought that I had fixed it by moving to update() but it the issue returned.

Long story short, #4774 fixes the issue for me.