Closed Bug 171519 Opened 17 years ago Closed 16 years ago

Mac: Problems editing Hebrew text in forms

Categories

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

PowerPC
All
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: xslf, Assigned: mano)

References

Details

(Keywords: fixed-aviary1.0, Whiteboard: fixed-aviary1.0, [fixed on trunk])

Attachments

(6 files)

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
Summary: Mac: Problems editing Hebrew text in forms → Mac: Problems editing Hebrew text in forms
Tested now with os 9.1 (yeda) and 1.2b- thee bugs are here also althgh a bit
less sever. very annoying
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: MacOS X → All
bug 172569 might be related
Depends on: 119860
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.
Flags: blocking1.4?
Blocks: 115711
mozilla1.4 shipped. unsetting blocking1.4 request.
Flags: blocking1.4?
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
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.
This is even worse on 1.7a Mac OS X 10.2.8, see attachment
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.
(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.
(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.
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.
Flags: blocking1.8a? → blocking1.8a-
(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?
(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)
(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...
(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.
And that's with Curior New as default fixed-width font.
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.
The font used in the screen shot is Lucida Grande.
I adding depedency for bug 120401
Depends on: 120401
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.
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.
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.
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
Status: NEW → ASSIGNED
Assignee: mkaply → romano_a
Status: ASSIGNED → NEW
Whiteboard: fixed on trunk
Keywords: fixed-aviary1.0
Whiteboard: fixed on trunk → fixed-aviary1.0, [fixed on trunk]
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.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
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.