Uploading does not URL-encode the link at the end of the upload

[Sa'ar Zac Elias]

Demonstration

• Open the demo and open the Image dialog.
• Go to 'Upload' tab and upload a file whose name contains characters that should be URL-encoded.
• After the upload is finished, sometimes a JS is thrown and the dialog does not switch to the 'Image Info' tab. in that case, switch manually to this tab.
• Take a look at the URL field. The characters that should be encoded (along with the space of the 'Public Folder' directory in the path) are not URL-encoded.

(For comparison, click on the 'Browse Server' button and select the file you have uploaded and notice that those characters are encoded)

[Alfonso Martínez de Lizarrondo]

CKEditor shouldn't do anything to the url sent by the upload script, so if anything requires escaping it must be done there or it would be impossible to use CKEditor with anything outside the typical setup of uploading files and return its path.

[Sa'ar Zac Elias]

The problem here is, as I said, when the URL after the upload is not encoded, a JS error is thrown and the dialog does not switch back to the Info tab.
Actually, I've just noticed that the selected file name is for some reason not fully encoded too (tested with /userfiles/images/Public%20Folder/%D7%A2%D7%A2%25%25%23%23@@55(1).png), and a JS error is thrown when clicking OK to insert the image, so encoding the URL might be the only way of solving this bug.

[Alfonso Martínez de Lizarrondo]

#5527 is an example of why the encoding can't be done at the js side because it lacks the context to understand what are the parts of the url and how each part must be encoded.

As long as the "file name" is a valid string, no js errors should happen and that value should be shown in the URL, without need to do any extra encoding.

[Sa'ar Zac Elias]

I see what you mean, so in that case another solution should be fonud to the bug i presented, because there is no reason a file named '/userfiles/images/Public%20Folder/%D7%A2%D7%A2%25%25%23%23@@55(1).png' will trigger an error.
Anyhow, CKFinder might have a related problem, because it yields inconsistent result.

[Jakub Ś]

I have tried reproducing this in current CKFinder 2.3.1 but no error occurred.

If I remember correctly - There was some research and work (concerning encoding and server settings) made that resolved issues with files containing non-iso or 'must encode' characters in their names.

I'm closing this issue as fixed.