Open jodator opened 5 years ago
Yeah, you're probably right because this is something we ignored to speed up development. It could be a tough one to debug (React).
OTOH it's not that critical because you can disable the inspector and then check out the memory leaks, right?
Yes you could - but there's no OFF switch for our manual test to not load the inspector at all for manual memory leak related tests.
If you don't expose it as Window.editor
, it won't load automatically.
BTW, wouldn't this be enough https://github.com/ckeditor/ckeditor5-inspector/issues/42?
There was more text but I've checked #42 and I see that the inspector listens to destroy
event and then it detaches itself :+1:.
The only thing that probably (I didn't tested #42 for leaks) would be to get read logging the editor instance to the console. I'm not sure if this is really useful. The better would be logging the editor instance to the console similarly as the commands can be logged to the console using >_
button.
@oleq As your request from https://github.com/ckeditor/ckeditor5/issues/1814#issuecomment-502586982 unfortunately the changes from PR: https://github.com/ckeditor/ckeditor5-inspector/pull/46 does not help. I'm worried that it is either React itself or there are still some cleanups to be done:
On the above screen cast I do:
CKEditorInspector.destroy()
Unfortunately somethings retains references to the the editor.
There are at least two problems:
Logging to a console editor instance - until the console is cleared the editor will remain no available for garbage collector (below only logs the editor without instantiating the inspector):
The inspector itself hold some references to editors and thus they are not cleared (the console was cleared):