User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060331 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060331 Firefox/1.6a1 When writing a text with at least one hebrew char and clicking the spacebar causes the text to move left. It may be because of the font Verdana. Reproducible: Always Steps to Reproduce: Watch the testcase. Enter Hebrew char and press spacebar and press spacebar couple of times. Actual Results: Text is moving left. Expected Results: Text should not move. You may check if the problem is the Verdana font.

This bug is regressed bug. In Firefox 1.5.0.1 this bug does not occur.

Using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060417 Firefox/3.0a1 If I load attachment 217031 [details], I see hebrew text slightly to the right of the center of the textarea. If I the put the caret at the left end of the textarea, and press backspace to delete the spaces, the text begins to move towards the right as I delete the spaces.

Confirming based on comment #4, which basically describes the problem in the reverse order (compared to comment #0): Adding spaces causes the text to shift to the left, deleting them causes it to shift (back) to the right.

I found another problem that may be relate to this bug, steps to reproduce: 1. go to "Testcase for non-Hebrew speakers". 2. put the caret before or in the elsewhere in the word 'ωμεν'. 3. type one or two hebrew letters and the word is displayed incorrectly or the word disappear. Another way to make the word disappear: 1. go to "Testcase for non-Hebrew speakers". 2. put the caret after the letter "ω" and press "ω" again.

I'm guessing this is cairo-related (I can't reproduce on Mac). This seems pretty bad. Nominating for blocking 1.9a1.

Another problem: (sorry for posting too much) 1. go to "Testcase for non-Hebrew speakers". 2. put the caret after the letter "í" (end of the word) 3. press backspace couple of times. Result: The caret is displayed on the text and the letters not deleted. Expected Result: The caret should not be on the letters and the letters should be deleted.

I found another problem when selecting text. When using Verdana font, there are white spaces when selecting hebrew and english text. Testcase for this problem is coming.

I reproduced on build 20060226 but I could not reproduced on build 20060222. Does it imply this is Cairo-related?

(In reply to comment #11) > I reproduced on build 20060226 but I could not reproduced on build 20060222. > Does it imply this is Cairo-related? > Yes, almost certainly.

The tightest range I could find is: 20060222-20060224

I'm getting reports that this is making RTL textareas on Windows very hard to use, and as a result, bidi editing on trunk is getting even less testing than it usually does (which isn't enough anyway). I wonder if this can be prioritized so that it won't block the discovery of other bugs.

Changing component to GFX: Thebes because it's cairo-related.

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

The manifestation of this bug has widened sometime between 2006-10-26 and 2006-10-31: see dupe bug 359008.

Screenshot of attachment 235374 [details] taken with sm trunk build 2006-10-31-14 on Windows XP SP2.

I understand now what is happening here, but there's no point in working on it before the new textframe lands. When we measure the text we measure word by word, but for the width of spaces we use a fixed value taken from the current default font. When we draw, we draw the whole contents of the text frame including spaces. This means that when font substitution occurs, as it must here because Verdana contains no Hebrew, the spaces are drawn in the substituted font, not the default font, and don't necessarily have the same width that the measuring code assumed.

With the new textframe turned on, this bug does not occur.

this was fixed by my checkin for 332649.