171519 - Mac: Problems editing Hebrew text in forms

Status: RESOLVED WORKSFORME

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

Description

[Shoshannah Forbes]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20020922
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20020922

Editing Hebrew text in textareas in mozilla under OSX (10.2.1) is still very
problematic, even  with the recent nightlies .
* Selection of text is incorrect: where you click and drag is not what is
highlighted, and was is actually selected is completely different.
* insertion point when clicking in the middle of the text is incorrect.
* mixing Hebrew and English text results in the text appearing one on top of the
other.
* After a paragraph or two of Hebrew text (pasted or typed) there is a
noticeable slow down in the display- you can type a full word and only after a
delay you see it displayed. The more text you have, the slower it becomes
(memory leak?)

This makes using CMS systems and participating in message boards extremely
difficult.
These issues affect mail and composer as well.
I have not seen them to this extent on windows98

Reproducible: Always

Steps to Reproduce:
1. go to any Hebrew page with a form that has a textarea element
2. type some Hebrew text- a paragraph or so. 
3. Try to go back and edit some of your text

Actual Results:  
editing text is impossible

Comment 1

[Shoshannah Forbes]

Tested now with os 9.1 (yeda) and 1.2b- thee bugs are here also althgh a bit
less sever. very annoying

Comment 2

[Shoshannah Forbes]

bug 172569 might be related

Comment 3

[Prognathous]

Attachment: RTL textareas: Mozilla for Windows vs. Mozilla for OS X (1.4RC2)

The attached screenshot demonstrates many of the problems in this bug. The main
one is that typing spaces moves the whole sentence outside the textarea
(visible in the Mac screenshot -> the right side of the Hebrew text is
truncated). Another problem is that rtl and ltr text (digits) overlap each
other in the rtl textarea.

You can check the same testcase using
http://oren.gomen.org/mozilla/textareas3.html

This problem also effects the latest versions of Firebird for OS X and Camino,
but it doesn't happen on any Gecko-based browser in Windows, Linux or BeOS.

Prog.

Comment 4

[Asa Dotzler [:asa]]

mozilla1.4 shipped. unsetting blocking1.4 request.

Comment 5

[Shoshannah Forbes]

This bug makes editing wiki style web sites pretty much impossible.
See for example a screen shot of 
http://he.wikipedia.org/w/wiki.phtml?title=%D7%90%D7%A8%D7%A6%D7%95%D7%AA_%D7%94%D7%91%D7%A8%D7%99%D7%AA&action=edit
in the latest mozilla nightly

Comment 6

[Shoshannah Forbes]

Attachment: Editing wiki style pages becomes impossible- screen shot

Comment 7

[Prognathous]

Too many seperate issues. 

Xslf, how about reporting this as several seperate bugs, each with it own
testcase? I'll be happy to help with this task next week, when I'm back with
access to a Mac.

Prog.

Comment 8

[Nir Soffer]

Attachment: Screenshot of editing page in Hebrew Wikipedia

This is even worse on 1.7a Mac OS X 10.2.8, see attachment

Comment 9

[Asaf Romano (gone)]

Since Mozilla 1.7a (Mac), RTL usse can't use mozilla's textarea at all. Every
enterd space cause the text (in the same line) to be shifed outside the viewable
space.

One weird issue is that the following css definition:
----------
textarea
{
    font: normal 100% Arial, Lucida Granade sans-serif;
}
----------
partly fixes (*very* partly. but still much better) a lot of the problems
mentioned, especially the shifting issue.

Comment 10

[Prognathous]

(In reply to comment #9)
> Since Mozilla 1.7a (Mac), RTL usse can't use mozilla's textarea at all. Every
> enterd space cause the text (in the same line) to be shifed outside the viewable
> space.

I don't think there were any new regressions in 1.7a that had anything to do
with this bug. The shifting text problem goes back a long way - see the
screenshot in comment #3 (taken using 1.4RC2). In fact, I'm not sure that
editing RTL texts in Mozilla/Mac was ever satisfactory.

Prog.

Comment 11

[Asaf Romano (gone)]

(In reply to comment #10)
> (In reply to comment #9)
> > Since Mozilla 1.7a (Mac), RTL usse can't use mozilla's textarea at all. Every
> > enterd space cause the text (in the same line) to be shifed outside the viewable
> > space.
> 
> I don't think there were any new regressions in 1.7a that had anything to do
> with this bug. The shifting text problem goes back a long way - see the
> screenshot in comment #3 (taken using 1.4RC2). In fact, I'm not sure that
> editing RTL texts in Mozilla/Mac was ever satisfactory.
> 
> Prog.


The shifting was there, but it was less drastic, compare Mozilla 1.6 to 1.7a.

Comment 12

[Herouth Maoz]

I have found that selecting a Windows-originating font (such as Courier New) for the monospaced 
font in the preferences tends to fix the main of these problems: text munging in mixed Hebrew-
English.

Work is still slow when textbox contents are long.

Text selection works well if one drag-selects, but not for double clicking a word (double clicking a 
word in Hebrew which has English before it will select word before and word after it).

This workaround may help in determining the cause of the problem.

Comment 13

[Simon Montagu :smontagu]

(In reply to comment #12)
> I have found that selecting a Windows-originating font (such as Courier New)
for the monospaced 
> font in the preferences tends to fix the main of these problems: text munging
in mixed Hebrew-
> English.

What is the default monospaced font?

Comment 14

[Shoshannah Forbes]

(In reply to comment #12)
> I have found that selecting a Windows-originating font (such as Courier New)
for the monospaced 
> font in the preferences 


Hmm... Does Gecko actaully use that font? My font selections fail to register
(see bug #120401)

Comment 15

[Asaf Romano (gone)]

Attachment: Mozilla default preferences for hebrew fonts in OS X

(In reply to comment #13)
> (In reply to comment #12)
> > I have found that selecting a Windows-originating font (such as Courier
New)
> for the monospaced 
> > font in the preferences tends to fix the main of these problems: text
munging
> in mixed Hebrew-
> > English.
> 
> What is the default monospaced font?

Defaults are empty...

Comment 16

[Asaf Romano (gone)]

(In reply to comment #12)
> I have found that selecting a Windows-originating font (such as Courier New)
for the monospaced 
> font in the preferences tends to fix the main of these problems: text munging
in mixed Hebrew-
> English.
> 
> Work is still slow when textbox contents are long.
> 
> Text selection works well if one drag-selects, but not for double clicking a
word (double clicking a 
> word in Hebrew which has English before it will select word before and word
after it).
> 
> This workaround may help in determining the cause of the problem.

It doesn't work for me. I tried with both Monaco and Curior New.

Comment 17

[Asaf Romano (gone)]

Attachment: Current status (in 1.8a nightlies)

And that's with Curior New as default fixed-width font.

Comment 18

[Simon Montagu :smontagu]

It's interesting that in all the screenshots Hebrew is definitely *not* being
rendered in a monospace font. I suspect this is strongly dependent on bug 120401.

Comment 19

[Shoshannah Forbes]

The font used in the screen shot is Lucida Grande.
I adding depedency for bug 120401

Comment 20

[Asaf Romano (gone)]

Attachment: Result when i force apply sans-serif font.

i force apply this 
textarea
{
    font-family: sans-serif !important; 
}

and there are weird results:
1. withou entering many space at the end, there is no shifting.
2. when entering a lot of spaces there are two different result (depends on
numnber of characters in line)
2.1. space appear in the start of the line AS AN  ADITION to the spaces at the
end.
2.2. after manyt spcaes, shifiting is comming back

Force applying monospace doesn't help/damage_more for me.

Comment 21

[Asaf Romano (gone)]

maybe related:

http://lxr.mozilla.org/mozilla/source/gfx/src/mac/nsDeviceContextMac.cpp
http://bugzilla.mozilla.org/show_bug.cgi?id=95978 (has a reviewd patch)

Comment 22

[Herouth Maoz]

Those who tried Courier New - was that a font that came with the Mac or was it a Windows font?

I used the one from Windows. I think that's what made the difference.

And as far as I can determine, the Hebrew text is rendered in Lucida Grande, whereas the English 
is rendered in Courier New. I don't know why, but they simply don't interfere with each other. It 
could be because I'm still using Jaguar, I don't know.

Comment 23

[Asaf Romano (gone)]

As this seems to be a result of bug 120401, maybe the information here:

http://bugzilla.mozilla.org/show_bug.cgi?id=120401#c21

can help. As you can see, Mozilla doesn't take care font.name.monospace.he which
has to be used by the textarea widget.

Comment 24

[Asaf Romano (gone)]

Test build without this problem (from bug 120401):
http://www.miloberi.com/pub/firefox-powerpc-apple-darwin7.4.0.dmg.gz

be aware that the XP bugs in hebrew forms are ofcourse there

Comment 25

[Asaf Romano (gone)]

We fixed the mac-specific issues (bug 120401).

You may still notice:
 * bug 207186 (All/All)
 * bug 188294 (Mac)

Notice that you need to choose some monospace font for Hebrew.