Ckeditor4: Pasted images from RTF as WMF images are not converted to images recognized by browsers

Created on 13 Jul 2018  路  8Comments  路  Source: ckeditor/ckeditor4

Type of report

Feature Request

Provide detailed reproduction steps (if any)

  1. Open document snippitRTF.rtf.zip
  2. Copy its content to CKEditor

Expected result

Images will be converted to base64

Actual result

Error: Not allowed to load local resource: file:///... appears.

Other details

  • Browser: Any
  • OS: Any
  • CKEditor version: 4.10
  • Installed CKEditor plugins: full-all
pastefromword wontfix support feature

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.:

<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.

All 8 comments

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:

  1. clicked right mouse button into image in Word
  2. Use save image as option
  3. Save it as png file
  4. remove origin images from document and embed freshly saved one
  5. Paste such content to CKEditor
    screen shot 2018-07-17 at 17 53 42

@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:

  1. In Chrome, copy the contents for the attached file above,
  2. Copy the contents to clipboard, and paste into the instance in this demo,

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.

snippitRTF.zip

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.

Was this page helpful?
0 / 5 - 0 ratings