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

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

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

can you make a screenshot ?

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

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

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

bug 112110 (Windows) is related ??

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....

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

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.

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.

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.

this is not a camino specific bug

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

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

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

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]]

(In reply to comment #19) > &#8235;* [[&#1497;]] > &#8235;* [[&#1497;&#1460;]] > &#8235;* [[&#1491;]] > &#8235;* [[&#1497;]] > &#8235;* [[&#1513;]] > &#8235;* [[&#1497;&#1497;&#1460;&#1491;&#1497;&#1513;]] &#8235; is Unicode Character RIGHT-TO-LEFT EMBEDDING - U+202B HTML Entity (decimal) &#8235; – (hex) &#x202b; UTF-8 (hex) 0xE2 0x80 0xAB (e280ab) %E2%80%AB %e2%80%ab I suspect that MediaWiki "sees" the &#8235; character as the first character in the line. This is why these lines are not rendered as individual list items.

*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 ' &#770;' move the caret over this character it will take you two keystrokes in order to move over the Unicode character ' &#770;' 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 ' &#770;' and '"' with the "'s then add as many characters before '"' and ' &#770;' and '"' unless ' &#770;' is at the end of the editbox you can see that " &#770;" 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.

See bug 283415

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.