I don’t think so. While I don’t fully grok the issue the PR fixes, in my case it doesn’t seem to be the type of the pasted element, but the fact that the dropzone that receives the event doesn’t filter by that type. I’m basically editing text and yet the dropzone behaves as if any sort of paste should be handled as an import. This manifests itself for me since the changes I made to CM mean that the event target is no longer a textarea.
In an empty TW without these settings, if the content type of the tiddler that is being edited is empty, a dropzone with the contentTypeFilter is called, but because it doesn’t do anything, since the target is a textarea, the event gets propagated to another dropzone which again does nothing for the same condition. If the content type is for javascript, only the second dropzone is called and it does nothing.
In my TW, when the tiddler’s content type is empty, the first dropzone gets called, it enters the “!textarea” condition but in there it calls readFileCallback that does nothing due to the content filter. But since it is in the condition body, it stops propagation so the second dropzone is not called. When the content type is for javascript, only the second dropzone is called, it goes into the condition, but since it doesn’t have a filtertype, it handles the import.
I don’t know how to do it, but I think the first dropzone should remain when the tiddler that is edited has a content type of json/javascript (or other text formats). While were at the subject, it seems to me that import should trigger when the content type filter doesn’t match the pasted type (it should be a whitelist), and not the way it is now (when it acts as a blacklist).
