Closed Bug 119860 Opened 19 years ago Closed 16 years ago

Incorrect caret position when writing in Hebrew forms


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

Not set





(Reporter: xslf, Unassigned)



(Keywords: intl)


(3 files)

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

Currently there is only a stub implementation at
Assignee: mkaply → ftang
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
Ever confirmed: true
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.
*** Bug 112110 has been marked as a duplicate of this bug. ***
OS: Mac System 9.x → All
Hardware: Macintosh → All
Target Milestone: --- → mozilla1.2beta
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.
Severity: normal → major
Hardware: All → Macintosh
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
Component: BiDi Hebrew & Arabic → General
Product: Browser → Camino
Target Milestone: mozilla1.2beta → ---
Version: Trunk → unspecified
Blocks: 171519
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

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

Blocks: 240501
Keywords: intl
this is not a camino specific bug
Assignee: ftang → nobody
Component: General → Layout: BiDi Hebrew & Arabic
OS: All → MacOS X
Product: Camino → Browser
Version: unspecified → Trunk
I don't see this problem anymore (see bug 120401), can someone verify?
Depends on: 120401
WFM. Feel free to reopen if you see this issue again.
Closed: 16 years ago
Resolution: --- → WORKSFORME
Verify fixed in both Firefox 1.0 and latest Mozilla 1.8.x trunk.


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

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

* '''[ 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 . 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;

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 which will be REOPENED and more others.

Probably more investigations are required at
== 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.

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

*note about moving the caret*
plase go to
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 also

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.
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.
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: zach → layout.fonts-and-text
You need to log in before you can comment on or make changes to this bug.