showblocks confused by pathnames including spaces

[NicHolt]

If the pathname for CKE includes e.g. a space, then paths in the cssTemplate may include %20, which the regex matches against %2. The result is that the images denoting the block type are missing. Fix is to use something other than %<numeral> as the paceholders in the cssTemplate.

[Jakub Ś]

Just like in #8612

@NicHolt Could I ask you first for a reproducible TC (E.g. sample HTML file) so that we could see the problem on our own?

[Jakub Ś]

@NicHolt any updates regarding this ticket?

[Jakub Ś]

@NicHolt could I perhaps ask you to provide such template. The one you were using for your tests?

[NicHolt]

Whilst developing various extensions, I am testing on my local PC.

So filenames are of the form X:/documents and settings/myprofile/my docments/filename ...

The URL encoded version of these local paths replaces spaces with %20.

As a result, the image paths in the CSS template are not recognised by the local OS.

Local file paths should either be universally converted to ​file:// protocol URLs, or they need to be reverted to local OS paths.

[Jakub Ś]

To reproduce:

1. Place CKEditor locally E.g. C:/Users/me/Documents/my editor/ckeditor/
2. In templates.js add the below code (please adjust paths)

   {
   	title: 'bb',
   	image: 'template3.gif',
   	description: 'bb',
   	html:
   		'<div style="width: 80%">' +
   		'<img alt="" src="C:\\Users\\me\\Documents\\my editor\\ckeditor\\_source\\plugins\\templates\\templates\\images\\template3.gif" style="width: 102px; height: 76px;" />'+
   		'<img alt="" src="file:///C:/Users/me/Documents/my editor/ckeditor/_source/plugins/templates/templates/images/template3.gif" style="width: 102px; height: 76px;" />'+						
   		'</div>'
   }
   

3. Try to insert template 'bb'

Results:

• First image path is not recognized by Safari, Opera and Firefox
• Second image path is recognized by all browsers.

I was not able to reproduce this issue in any other way.

[Jakub Ś]

Taking into account that I have tried many different approaches and I have only managed to reproduce this problem with templates plugin as described in comment_5 I think that this is user creating template responsibility to use file://.