Incorrect display of URL, file path including bidi data

[Tomer Mahlin]

Background

Display of text on the screen is governed by Unicode Bidi Algorithm (UBA). This is true for both platform level rendering, web browser rendering and CKEditor rendering. UBA provides good results for plain text but fails to preserve structured in case of structured text includes bidi (Arabic / Hebrew) characters. UBA provide various tools (i.e. Unicode Control Characters) which can be used to instruct it about structure of the text. Using those tools we can achieve perfect display.

CKEditor context

In CKEditor we see following types of structured text:

1. File paths

2. URL

When Bidi data is used as part of those cases, the display of data is completely incomprehensible. For example: c:\AAA\BBB\Aa\file.txt (capital letters refer to Bidi letters) will be displayed as: c:\A\BBB\AAAa\file.txt As you can see not only the order of folders names but also their integrity is violated. Judging by appearance, you would think that top most folder is A, while in reality it is AAA. You would also think that there is a folder AAAa, while in reality there is no such folder.

[Frederico Caldeira Knabben]

That's an interesting topic and I wonder what browser expects to have here.

These fields are NOT there to show the user the hierarchical folders path of a file, but instead to give the full path of such file *to the browser* so the image can be properly displayed or uploaded.

So the first question is: are this (visually strange) URLs/paths broken? I mean, is the image been properly displayed in that case?

Then, when it comes to try to fix it, do you see any technological solution for it that makes sense?

Finally what is the behavior outside CKEditor. For example, how upload fields somewhere else behave in the very same case?

[Tomer Mahlin]

are this (visually strange) URLs/paths broken?

The image is properly displayed, the path can be used. It is only impossible to see what does it refer to since visual display of path is completely broken.

any technological solution

There is a solution which Dojo provides. Very similar one can be developed in CKEditor (it is pure JS based)

Outside CKEDitor

IBM products have full support in this area.

[Frederico Caldeira Knabben]

Replying to tomerm:

There are a few things that concern me:

1. We cannot hack the editing field, because users may type on it.
2. Users may copy the URL from the field and paste in the browser address bar. We should not break this. In other words, the most important is having valid URLs there.

Outside CKEDitor

IBM products have full support in this area.

I was talking about native HTML, like input and upload fields. I have the impression that what we have is simply the native behavior of browsers.

[Tomer Mahlin]

Natively HTML / browsers don't provide any support unfortunately.

For INPUT of type FILE. As you can see from the example, the field is already disabled. Namely people can type into it. They can only press on the Browse button, select some file, and see the full path in that input field. The suggested solution is to overal visually the input field with another one (which is also disabled), in which file path can be properly displayed. This way we don't hack anything in the original field, and at the same time provide proper display of the file path to the end user. How do we assure proper display of file path in the fake field ? Also with the help of UCC.

For URL. It is a simple input field (not of type FILE). Call back to it can be added to trace user modifications (copy / paste / typing / cursor movement etc.). UCC will be used to separate between the segments. This assures proper display. UCC can be removed on copy event to assure that URL is passed as-is to the clipboard.