After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 490241 - Bidi text editing in evolution mailer is almost impossible
Bidi text editing in evolution mailer is almost impossible
Status: RESOLVED WONTFIX
Product: GtkHtml
Classification: Other
Component: Editing
3.12.x
Other All
: Normal normal
: ---
Assigned To: gtkhtml-maintainers
gtkhtml-maintainers
gnome[unmaintained]
Depends on:
Blocks:
 
 
Reported: 2007-10-25 18:38 UTC by Oded Arbel
Modified: 2017-02-09 13:35 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20



Description Oded Arbel 2007-10-25 18:38:17 UTC
Please describe the problem:
When I'm trying to write mail in Hebrew using the Evolution mail composing editor, simple text editing features - like visual cursor movement - do not work or work in strange and unpredictable ways.

As a result, writing mail in Hebrew using Evolution is an adventure that I'm reluctant to embark on, to the point that I sometimes start another mail client for the sole purpose of writing one email in Hebrew.

I will now details some of the more severe behaviors:

Steps to reproduce:
For all the items listed below, start with an empty composer window with the cursor at the start of the text area (I have an LTR signature at the bottom, and I assume it doesn't matter):

* write a sentence in Hebrew and at the end write a number. then try to select the entire sentence by pressing <Home> and then <Shift><End> - the sentence is selected, except the numbers.
* Write a few words in hebrew, then a number, then a few more words. Now try to use the right cursor key to back through the sentence - you can't move past the number: as soon as you reach the right side of the number, the cursor is wrapped to the the left side of it again. Use the mouse to position the cursor on one of the words to the right of the number and try to use the left cursor key to get to the number - once you reach the right side of the number the cursor wraps to the left side of it and more left clicks skip the number.
* Write a few words in Hebrew, then a few words in English, then a few more words in Hebrew. Now try the cursor movement test again: moving left through the sentence works like with the above example of numbers, but moving right behaves differently - once you reach the left side of the LTR text the cursor wraps to the end of the line and stays there despite repeated hits on the right cursor key.
* The same sentence as above ("RTL ltr RTL"), position the cursor on the right side RTL text and click <Home> - the cursor goes correctly to the right side. Pressing <End> the cursor goes correctly to the left side. Now position the cursor on the left side RTL text and click <Home> - both <Home> and <End> take the cursor to the left side.
* For some reason, not sure how related, with my current version when I try the above trick with numbers instead of LTR text (pressing <Home> when the cursor is on the left side of the sentence) Evolution just hangs and I have to kill it.
* Mouse selection is very confusing when trying to select text which contains RTL, LTR and numbers - specifically there's no way to select RTL text followed by an LTR text unless there is a space after the LTR text which you are willing to also get. There are also numerous other discrepancies between how mouse selection works in evo's composer vs. a text editor like gedit.
* If an RTL sentence starts with a non-directional character, such as period, asterisk or dash, the sentence automatically gets LTR directionality which messes it up. It also happens with numbers, so you can't write numbered or bulleted lists in Hebrew.
* If there's a line that starts with a number and followed by non-directional characters and RTL characters (for example - a hebrew numbered list), with the cursor positioned one line above its impossible to use the <Down> key to move to the numbered list - the cursor simply refuses to move. This does not happen when a line starts with non-directional or LTR characters.

All the above issues are in Evolution's mail composer only to the best of my knowledge. Specifically I verified that none of these problems occur in gedit. There is a problem with CTRL-<Right>/<Left> movement being reversed on RTL text which is also shared with gedit, but there is a different bug report for that.


Actual results:


Expected results:


Does this happen every time?


Other information:
There are several more confusing behaviors that I haven't yet detailed here that wreak havoc with BiDi editing in Evolution, especially when "wrongly LTR directional" lines (like discussed in the last entry) start to pop-up, which are more complex to setup as test cases but I can do that if there is interest.
Comment 1 Oded Arbel 2007-12-12 16:54:58 UTC
Another issue which only lately I noticed, and I think its the worst of all the above behaviors:

* start an RTL sentence and end it with an LTR word, and press ENTER. now try to use a mouse to position the cursor in the previous sentence so you can add an RTL word at the end: its impossible to click anywhere in the sentence so that an RTL letter written would be added to the end of the sentence.
Comment 2 Oded Arbel 2007-12-16 12:29:54 UTC
Another issue which I've just noticed regarding BiDi email editing:
when pasting text with the mouse to an RTL paragraph, the text is always pated to the right of the current line (i.e. in the beginning) if the mouse is positioned to the left of the current line (i.e. trying to paste in the end). Pasting in the middle or at the beginning (on the right side of an RTL paragraph) works as expected.
Comment 3 Yotam Benshalom 2010-07-04 14:23:32 UTC
How come no devs reply here? These are long-standing bugs, and they really harm the usability of Evolution.
Comment 4 Yotam Benshalom 2010-07-07 13:06:02 UTC
Oded, I think you better set this as a GtkHtml bug. This is the component that does the actual editing for the Evolution mailer.
Comment 5 Arik 2012-11-07 12:31:34 UTC
Aren't GNOME devs planning to replace GtkHtml with something based on WebKit? (just something I read in a blog back then... I might be out of my element here...)
Comment 6 André Klapper 2017-02-09 13:35:46 UTC
GtkHtml is not under active development anymore. 
Evolution (its main consumer) switched to a WebKit backend a while ago. 
It is currently unlikely that there will be any further GtkHtml development.

Closing this report as WONTFIX as part of Bugzilla Housekeeping (bug 778387) to reflect reality. Please feel free to reopen this bug report in the future if anyone takes the responsibility for active development again.