textarea not working for IE11/FF(33)

[EugenMayer]

Using your example at http://micy.in/paste.js/ and also implemented it myself in a wysiwyg.

For chrome, its just fine, but FF and IE11 does not work in your demo nor in my case, when using the textarea.

I tried to debug it and it seems like the image is not "pasted" into the hidden div, but rather into the textarea itself, therefore https://github.com/layerssss/paste.js/blob/master/paste.js#L9 does not find the image and the event is not triggered

Could you assist me a bit fixing this? Thank you

[layerssss]

I'll look into it later today. Thanks for filing this issue.

[EugenMayer]

Iam also debugging, let me know when you start - i think it makes sense combining the effort :)

[EugenMayer]

It looks like this is more complicated. In my case, i even use "body" (CKeditor) but what happens in Firefox is:

• when designMode is on ( for textarea its always on ), so contenteditable on a div

Firefox always pastes into the designArea, no matter what you focus in the paste even. In addition, the clipboardData API does not work for FF right now for images, its still work in progress.

[EugenMayer]

I forked you jsfiddle to extract the core issue, thats basically it : http://jsfiddle.net/oyLjkqqm/1/ Eventhough, in both cases the image apears, in the designMode on case, its native FF and you cannot "grab" the image in the paste event / or in the pasteArea

[layerssss]

Hi, thanks for help. I managed to tweak your fiddle to make to work (partly). This is the result: http://jsfiddle.net/vjk9fx6y/1/ . I changed the appendTo into insertBefore to make it work.

This is because paste.js used a hack to get pasted image in firefox. $.paste() actually generated a contenteditable div. And when handling focus events, it actually focused the hidden contenteditable. After few milliseconds, we try to retrieve the image's src from the contenteditable. This is because "firefox have already help us to convert any embeded images or (just one piece of image data) into base64 encoded datauri".

This hack currently works under firefox. However it may still cause some unexpected behaviors with visible contenteditable. including:

1. When user had done pasting. The visible contenteditable lose focus. Because the hidden contenteditable is now focused.

I'll try to work up a fiddle example as how to use contenteditable with paste.js to avoid these issue. Could you please tell me if you find more issues like this when working with contenteditable-based editors like CKEditor.

[layerssss]

oh, I'm sorry. It's all about focus. Any inputable element (textarea, div[contenteditable]) will not be able to really focused. This will be a serious issue.

[layerssss]

I tried to debug it and it seems like the image is not "pasted" into the hidden div, but rather into the textarea itself, therefore https://github.com/layerssss/paste.js/blob/master/paste.js#L9 does not find the image and the event is not triggered

Right, firefox won't let your image been pasted into another element if you just delegated the event( in the second fiddle ).

[layerssss]

In order to get the image in firefox. you have to really focus the contenteditable. no event delegating. But if we want to avoid losing focus (like in http://jsfiddle.net/vjk9fx6y/1/ ) . We need to directly retrieve image from the visible contenteditable. We also need to avoid affecting other browsers. Since other browser won't convert images into base64 encoded datauri when pasting image data into contenteditable:

1. Chrome simply ignores it.
2. Safari generated a fakewebkituri://... , which is no use at all. (it's not the same origin as the webpage)
3. IE, i don't remeber, need to get a vm to have a try.

[EugenMayer]

Hi, now we are in sync. Thats what i could inf out alos. For FF, one will need a "application" specific implementation, since you need to be able to seperate "new images" (pasted" from already processed images, e.g. in a WYSIWYG editor - means we need to make it possibel to define a callback to decide wheather an image is "just uploaded" or not - with a default implementation

I have rewritten the library to be more flexible, using a class to be able to handle tool methods a flexible way, just have a look at https://github.com/EugenMayer/paste.js/blob/origmaster/paste.coffee

I would love to start working from this base on. I could at least see that my base cases are still working, i also used your logic as far as possible, to not brake logic.

https://github.com/EugenMayer/paste.js/blob/origmaster/paste.coffee

[layerssss]

Another instant idea:

1. first capture the keyboard event. get the content before pasting.
2. let the pasting happen,
3. check what's been added into the contenteditable,
4. if it's just a single image. Then we convert (no need to convert in firefox) it, and remove it. (and let the user handle it)

It would be much cleaner.

[layerssss]

About the API, I think it would be better to treat contenteditable as first citizen. About others:

1. normal div (non-inputable), developer need to handle the focus / blur logic by them selves, since they need to know what happens wont broke their logic
2. input. the same as normal div.

[layerssss]

that's like

pm = new $.paste $('[contenteditable]')[0]
pm.on 'pasteImage', (datauri)->
  upload dataurl, (uri)=>
    $("<img src='#{url}'/>").appendTo @

[layerssss]

for other use (div, textarea), user needs to manually construct a contentediable (or we can provide a shorthand function to constructor one) as the container argument.

[layerssss]

by the way, I like the coffeescript class. being using it a lot in other projects.

[EugenMayer]

i have now implemented firefox support in the pull request - lets move this to the pull request and close this issue here?

[layerssss]

ok, let's close this issue and move to the pull-request.