Opened 11 years ago
Last modified 11 years ago
#11007 pending Bug
Incorrect display of URL, file path including bidi data
Reported by: | Tomer Mahlin | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | UI : Dialogs | Version: | 4.0 |
Keywords: | Cc: | Tomer Mahlin, Teresa Monahan, Amir |
Description
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:
- File paths
- 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.
Attachments (2)
Change History (7)
Changed 11 years ago by
Attachment: | CKEditor_FilePath.PNG added |
---|
Changed 11 years ago by
Attachment: | CKEditor_URL.PNG added |
---|
comment:1 Changed 11 years ago by
Keywords: | bidi structure text removed |
---|
comment:2 Changed 11 years ago by
Status: | new → pending |
---|
comment:3 follow-up: 4 Changed 11 years ago by
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.
comment:4 Changed 11 years ago by
Replying to tomerm:
There are a few things that concern me:
- We cannot hack the editing field, because users may type on it.
- 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.
comment:5 Changed 11 years ago by
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.
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?