Feature Request
Images will be converted to base64
Error: Not allowed to load local resource: file:///... appears.
What I can tell here is that img tags produced by Word here looks like the imgs that we're handling already, and the img matcher founds them.
The problem is that hex data are not found correctly, as the array of image hexes is empty.
I see that RTF data type contains a little of text so the images should be there.
Also I can repro it in other browsers, so I'll change the description to be browser independent.
It seems that issue is related to image encoding. Currently pasting images from word supports png and jpeg files.
I suspect that during embedding image inside RTF document, there is lost information about source image file and remain only bitmap format. At lest from provided test file seems like only bitmap is copied to clipboard.
Situation is a little bit more complicated, than I thought.
RTF clipboard contains only image saved as wmf
rtfdocument.rtf.zip
This file format is not possible to embed as img tag and would require some middleware converter to bmp. More info about wmf might be found here https://msdn.microsoft.com/en-us/library/cc250370.aspx
It's definitely not trivial task and more likely feature request.
I've made a simple test:
save image as option
@mlewand do we want to continue this task. It would require dig through wmf format and write some smart converter in CKEditor. As we don't have access to source images in png or jpeg format in this document.
I tried to create such document in Word2013 with no success. In all cases when file was saved then still jpeg or png information was preserved in it.
I need more details how create such document as attached to this bug report. Currently it looks like really rare bug which only exists for this document.
We got no more information on that one. It can be reopened if we get more info and once we can confirm the issue.
We got no more information on that one. It can be reopened if we get more info and once we can confirm the issue.
I'm very sorry for the late reply on this:
The file was created using Adobe Framemaker (exported into RTF)
Reproduction Steps:
Result:
Images do not upload nor are they visible in the editor (they are pasted with local paths)
NOTE: Images get pasted and uploaded in IE11 nicely. This is the only browsers where paste/upload from RTF works.
I've made some more detailed research and situation looks as following.
Clipboard data vary between browsers. Most popular browsers (Chrome, FF, Edge, etc.) embed such image as link to file system location e.g.:
<img width=31 height=31 src="file:///C:/Users/CKSource/AppData/Local/Temp/msohtmlclip1/01/clip_image002.png" v:shapes="_x0000_i1026">
To transform such link we cannot just read data from this path, because it's security vulnerability. (Possibility to read data from file system without noticing user is very insecure for the user.)
That's why we are forced to read such data from text/rtf clipboard which usually poses encoded image in jpeg or png format. And this approach is working for regular documents created in MS Word.
In case of document attached to previous comment text/rtf clipboard does not contain image in jpeg nor png format. It looks like, there are data stored in WMF format. Adding support for such format is a feature request.
So why it's working differently on IE11?
IE11 poses a feature: https://blogs.msdn.microsoft.com/ie/2013/10/24/enhanced-rich-editing-experiences-in-ie11/ which automatically converts such links to base64. So conversion is not done by CKEditor but by browser itself. We receive image which does not contain link to file system as it happen in popular browsers but it contains already base64 image e.g.:
<img width="31" height="31" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAB8AAAAfCAYAAAAfrhY5AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAOxAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAV1SURBVFjDxZd7TFN3FMe7ZRlCS3t7acER3ebGYlzmpsuyJXNZtpi4yf5Ysrh/Fs32xxKXORHZVAQmtAtYQJBSqk7RCoWCwKgIKuIDa6GCDB/gYzAUH6kT7LhqeZRH+e7cq2wrlhZi1CYnaXt/v/P5nXPP6ydSqVSipyUivV4/z263N7lcLs6n3O3hWhrquV912dya1THckpVruM9XruN+WBnNZWo0nLWmmnN13+T86iHhmQLcYDB8BB+fwTs9qK2pxqpULRamGTA/9wgiTM0IL2jG9ILTmGU6jbm7rfgwswjfJGehpLQUnP26L5XgmX7hlkMH8WX8RoSlFEFcfgWSY/fAWAfANgPM74CsCcJ3ef0ggmudEO//C/Ks/fg4Ng0moxGj/b1Thw+QtZqMLMyI24Jpe68h5BSgrBtA6IlehBJIVtaJiE27MSdjN5iCi1DaRhBqoWfWPihorbimB7KUEiyP/wVdnR2Th/fe7sKKBDUkaWYwtmGE2gZJsVMQJX1nyq8hctln2K9icDZXhOhV88AazkB5cvjfdaF0UJYOEbirCYui4nC59Zx/+FCvE6sTkxGkrRasFSwdU0gir3cjQmtClZqFoyICaBWjxyzCAlUCpCfcD61XNo4isPgSPo2KR/fVy77hO7bnQpZcDJY2jVc0Bp+VUQRbznPA+SCgPQCO30R4/+c4r3BeFPwBchuwYkMKRvqc3uFtZ5oxJyYV0rpB4d2NVzLmdmnZDXz94yK05Ilw0ShCTNQbYHc0kttHvO7hhfciq8qHuaTEOzw2bTOCjOcIMDShEkHoubTcjojsUsymVyAraofCNux7D2WI5JADi9dr0M85POGD/X14c8NWct2AV9f9J/co2l2QH3TghfRyzEoxQG5spUxw+YaTsLxnMvaiuqrSE37b4YBYdxjKU6O+lRBYWuVAZPRSnNQ9i45iEdRrX4Mi5xiUDW6/ewP2tCMuZ6cnvOOGHVLzFWGBz9Pb3AjfUo0ySrPBo9OBP5+/H3AJsZBahn17jeJIUvM3vsgyesJbOjoh9xEwY8LUufG6zgiLTo5b+14CWgJw54AIizVrITlKsXKiz+d+OUX+e5l7POGNbVeEyjQZ+By9CbXZLLr2vSjAe6pE+GTjOiq9/uEKKsmvpI6D17d1CgXhccOV1Aump5Z5wpvI8pAnYHkIWT47rdgTfv7yVcit/tLsUeG9YKj+f7B5HLzTfhPBxReFAvLY4HX9CDrQha+0+Z5wrodaYEYlBd3oY4MrqRVPKzyPlK3j8nzY5cKCBK0wLExU1x8JftwppPLM5AI0WGofru0Z+m2QbLVAIVSqe37htyqmAKeGJDZ3YukGDUYGeh+Gd1G/XRCtgvgwN2GlG4Mf17Horpw5OTj9x5DVM9bpYDt6eOJ+Xl2xF+G0SMa3VQoQb/DZ2UVo3hmAoaZg4FwA7lKFi9z4k/cKR9kTQvVDkl6B9Cwd4B7xMUaNjiInZwvYRAOYelJWP+BZoU66wW6zIT+RwG0ikmdgLxLh3cQkSK0jnqlKscODg6jpfLc+CUN3uUkMkEMuaLNzEBarh+QI51n5yBvMESfmr0/ETnUYzFoGy6IXgi28QMPE/9KU8llGhw/WlOP7eDWc3bemMjq7sY/m73dikoURiFek4GsAP8FSPDDHyKr8swjLrYO0svv+AEIHEwZMer+BJe14eW0WtDo93A9GpynP7df/uIDETVq8laCDdLsV08xXIaX5XE6zOnvmvshJZDRMBFbaEZTXjFfVu7BcnY7TVsujXRoeBAJutF9CvqkYUfo8RG4uxNtphZiZYkI4XSbmphZiYWYhvtXlQbcrH61NjcKrm9SNJSkpieF/PEnhmQL8ad5S/wFscTF7C2DRIAAAAABJRU5ErkJggg==" v:shapes="_x0000_i1026">
This is a reason why image from this document are working on IE11, but are not working on Chrome or Firefox.
Security reasons does not allow CKEditor or any other page to have access to user's file system, and that's why we cannot copy or simulate native IE11 solution to work with other browsers.
Thanks @msamsel for insights, I'm changing issue type into a feature request. Now the feature request itself is valid, as it could be done if one wrote a converter from uncommon WMF format to something widely recognized like jpg or png.
However situation like that is very rare and I believe it would be much better for mentioned Adobe solution to use any commonly recognized image format like bmp, jpg, png for better interoperability. The cost of creating converter for WMF would be extremely high rendering this feature unfeasible for us.
Most helpful comment
I've made some more detailed research and situation looks as following.
Clipboard data vary between browsers. Most popular browsers (Chrome, FF, Edge, etc.) embed such image as link to file system location e.g.:
To transform such link we cannot just read data from this path, because it's security vulnerability. (Possibility to read data from file system without noticing user is very insecure for the user.)
That's why we are forced to read such data from
text/rtfclipboard which usually poses encoded image injpegorpngformat. And this approach is working for regular documents created in MS Word.In case of document attached to previous comment
text/rtfclipboard does not contain image injpegnorpngformat. It looks like, there are data stored in WMF format. Adding support for such format is a feature request.So why it's working differently on IE11?
IE11 poses a feature: https://blogs.msdn.microsoft.com/ie/2013/10/24/enhanced-rich-editing-experiences-in-ie11/ which automatically converts such links to base64. So conversion is not done by CKEditor but by browser itself. We receive image which does not contain link to file system as it happen in popular browsers but it contains already base64 image e.g.:
This is a reason why image from this document are working on IE11, but are not working on Chrome or Firefox.
Security reasons does not allow CKEditor or any other page to have access to user's file system, and that's why we cannot copy or simulate native IE11 solution to work with other browsers.