119860 - Incorrect caret position when writing in Hebrew forms

Status: VERIFIED WORKSFORME

(Core :: Layout: Text and Fonts, defect)

Description

[Shoshannah Forbes]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.7+) Gecko/20020111
BuildID:    2002201108

in textareas: the caret is quite a few pixles left then the actaul charqacters
being entered.
in input text fields: the caret is sometimes ok and sometimes not. However, it
always shows a bidi caret- but when typing in Hebrew (rtl) the caret is diaplyed
as an rtl caret (notice where the edge is pointing)
The same problem accors when composing Hebrew email

Reproducible: Always
Steps to Reproduce:
1.try to enter hebrew text in forms in hebrew pages (both logical and visual)

Actual Results:  see description

Expected Results:  caret should be OK

Few URLs with examples:
http://forums.ort.org.il/scripts/addform.asp?which_forum=307
http://www.exego.net/forums/NewMessage.asp?Fnumber=2

Comment 1

[Shoshannah Forbes]

This also happends on  bugzilla pages (in English) when the defoult encoding is
set at windows-1255

Comment 2

[Simon Montagu :smontagu]

We may have to implement the Bidi keyboard widget for Mac to get correct caret
behaviour.

Currently there is only a stub implementation at
http://lxr.mozilla.org/mozilla/source/widget/src/mac/nsBidiKeyboard.cpp

Comment 3

[Frank Tang]

can you make a screenshot ?

Comment 4

[Shoshannah Forbes]

more carful examination shows that the Hebrew Text is getting pushed to the
right, behind the text area, and the Caret is where the text should be.
In english (window1255 dewfoult encoding) the caret is a few pixels to the right
of the text. Screen shots are attached

Comment 5

[Shoshannah Forbes]

Attachment: Screen shot of Hebrew Caret

notice where the Hebrew caret is vs. the text. also notice that the text gets
pshed over

Comment 6

[Shoshannah Forbes]

Attachment: page set as windows-1255 english text

Comment 7

[Shoshannah Forbes]

Attachment: page set as windows 1255. input:text caret

Comment 8

[Frank Tang]

no clue how to handle bidi caret on Mac. cc nhotta too.

Comment 9

[John Levon]

bug 112110 (Windows) is related ??

Comment 10

[Shoshannah Forbes]

I does sound similar (as I commented there a  while back). 
What bugs me about this bug (here on Mac), that since the caret is in the wrong 
position, inserting text to a line with some text I already wrote becomes 
impossible at first try: I have to use trail and error to get it right, and 
hope that I do not bump into the freeze of bug 95228 on the way, which will 
make me loose data.
grrr....

Comment 11

[Arno Roefs]

*** Bug 112110 has been marked as a duplicate of this bug. ***

Comment 12

[Shoshannah Forbes]

This looks ok on windows 98 and mozilla 1.2a, but is still horribly broken in
the latest osx nightly builds.
It makes writing in message boards or writing Hebrew email nearly impossible-
you can not go back and fixed anything or edit anything in the text.
Also, on osx, when in a Hebrew page, the caret is a hEbrew caret- but a LTR
caret regadless of the writing direction.

Comment 13

[Shoshannah Forbes]

This was fixed in mozilla around 1.3, and was fixed in Camino nightlys after 0.6
however, this recently broken on camino again, and is still broken in camino
nightlies.

Comment 14

[Prognathous]

I think we're actually dealing with three different bugs:

1. Caret is incorrectly positioned in some cases.
2. Text being entered is pushed to the right, outside RTL textareas.
3. Wrong BiDi marker for RTL text (similar to Bug 230080 which was reported for
BeOS).

I'm not in front of a Mac at the moment, but if I recall correctly, neither bug
is Camino-only.

Prog.

Comment 15

[Asaf Romano (gone)]

this is not a camino specific bug

Comment 16

[Asaf Romano (gone)]

I don't see this problem anymore (see bug 120401), can someone verify?

Comment 17

[Asaf Romano (gone)]

WFM. Feel free to reopen if you see this issue again.

Comment 18

[Prognathous]

Verify fixed in both Firefox 1.0 and latest Mozilla 1.8.x trunk.

Prog.

Comment 19

[lɛʁi לערי ריינהארט]

Hallo!

It seems that I have no priviledges to REOPEN this bug.

I am using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Please go to
http://yi.wikipedia.org/w/index.php?oldid=7709&action=edit

The content copied here with "copy and paste" is (don't / never relay on "copy and paste"):
*note*
When this comment is saved all Unicode characters will be saved in &#nnnn; notation.


* '''[http://bugzilla.wikipedia.org/ bugzilla]-&#1508;&#1471;&#1512;&#1493;&#1468;&#1520;'''<br />
* [[&#1497;&#1497;&#1460;&#1491;&#1497;&#1513;]]
&#8235;* [[&#1497;]]
&#8235;* [[&#1497;&#1460;]]
&#8235;* [[&#1491;]]
&#8235;* [[&#1497;]]
&#8235;* [[&#1513;]]
&#8235;* [[&#1497;&#1497;&#1460;&#1491;&#1497;&#1513;]]
* [[&#1506;&#1489;&#1471;&#1512;&#1497;&#1514;]]
* [[&#1488;&#1463;&#1512;&#1488;&#1463;&#1502;&#1497;&#1513;]]

Go to the url from above. Please click in the middle of the first line. The caret should be there. Then press the key <end of line>. Then move the caret with the LEFT-arrow key (not with the right-arrow character by character.

I can not see anything strange. I see all "*" characters at the start of the lines. However when this form is stored MediaWiki saves the page as you can see at http://yi.wikipedia.org/w/index.php?oldid=7709 . This should be a list but for me there are only five lines. The *third* line looks as:
&#8235;* &#1497; &#8235;* &#1497;&#1460; &#8235;* &#1491; &#8235;* &#1497; &#8235;* &#1513; &#8235;* &#1497;&#1497;&#1460;&#1491;&#1497;&#1513;

*note*
It is quite strange that If I click with the mouse in the lines exept the first two and the last two and press the <end of line> key I will not be at the end of line of that line but at the end "of the paragraph".


This behaviour will confuse users / visitors from contributions on RTL wiki's. There are some workarounds and spending 15 min it is possible with the "trial and fail" method to make so such a rearangement that the page looks fine. This is not the scope of this comment here.

Please read about <br />, newline and paragraph at
bug 229367 <br> confuses our bidiness (punctuation before <br> at end of line starting with number doesn't follow paragraph directionality)
Reading bug 229367 I remembered a MediaZilla http://bugzilla.wikimedia.org/show_bug.cgi?id=3621 which will be REOPENED and more others.

Probably more investigations are required at
https://bugzilla.mozilla.org/show_bug.cgi?id=171519
== Mac: Problems editing Hebrew text in forms

best regards reinhardt [[user:gangleri]]

Comment 20

[lɛʁi לערי ריינהארט]

(In reply to comment #19)
> ‫* [[י]]
> ‫* [[יִ]]
> ‫* [[ד]]
> ‫* [[י]]
> ‫* [[ש]]
> ‫* [[ייִדיש]]

‫ is
Unicode Character RIGHT-TO-LEFT EMBEDDING - U+202B
HTML Entity (decimal) ‫ – (hex) ‫
UTF-8 (hex) 0xE2 0x80 0xAB (e280ab) %E2%80%AB %e2%80%ab

I suspect that MediaWiki "sees" the ‫ character as the first character in the line. This is why these lines are not rendered as individual list items.

Comment 21

[lɛʁi לערי ריינהארט]

*note*

I did not mention that I am using a German keyboard. This might have some impacts.

*note about moving the caret*
plase go to http://test.leuksman.com/edit/MediaWiki:Edittools
find 1) e)
there is a Unicode character ' ̂'
move the caret over this character it will take you two keystrokes in order to move over the Unicode character ' ̂'
I experienced same behaviour when moving over BiDi directional Unicode characters
I taught I would experience this at http://yi.wikipedia.org/w/index.php?oldid=7709&action=edit also

BTW:
edit a comment and insert the Unicode characters '"' and ' ̂' and '"' with the "'s
then add as many characters before '"' and ' ̂' and '"' unless ' ̂' is at the end of the editbox
you can see that " ̂" disapears

This relates to text wraping insise a editbox. I assume that the browser would be more customer friendly if text wraping would take care of such nonprintable Unicode characters (here in the Combining Diacritical Marks Block).
If I am not able to find a bug about this I will open one.

Comment 22

[Simon Montagu :smontagu]

See bug 283415

Comment 23

[lɛʁi לערי ריינהארט]

http://test.leuksman.com/index.php?title=User:Gangleri/tests/BiDi/caret&oldid=10716
is a page with user names used to test a function as described at Bug 320273
== BiDi: request for a "BiDi balancing function" to avoid BiDi overlapping between objects

This is not a normal wiki page and I don't know if it makes sense at all to mention it here.

However a few comments:
- When you edit the page and go in the line under "tests for bugzilla.mozilla" you can move with the cursor as if all the text is LTR.
- If you click in the line under "User talk:GangleriBot" and you click on <line end> the caret will move there. However you will not be able to see the caret if you press <begining of line>.

Writing this I remember the discussions from
bug 229367 <br> confuses our bidiness (punctuation before <br> at end of line starting with number doesn't follow paragraph directionality)

The number of nesting levels for the BiDi algorithm that should be supported by a browser is limited. Paragraphs etc. reset these levels (and <br> and newlines do not). But a EDITBOX does NOT have paragraphs.

I do not know what consequences result from this. I think that the editbox is not "browser rendering" and I do not know if recomendations aplay here. But the editbox should be helpfull / usefull for most users and easy to use.