From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4+) Gecko/20010914 BuildID: 2001091403 When selecting Arabic characters on the page, the selection does not start where the cursor is placed. Reproducible: Always Steps to Reproduce: 1. Go to http://unicode.org/unicode/standard/translations/arabic.html 2. Try selecting several arabic characters in one of the lines. You can see that, if you start at the beginning of the line, and select characters to the end of the line, the placement of the selection with respect to the cursor becomes much wider. 3. Actual Results: Selection is not in placement with where the cursor is Expected Results: Selection should be in the same place where the cursor is scrolling. Using Windows XP.

Changing to new, I see this behavior on w2k build 2001-09-17-05-0.9.4

I'm still seeing this on 2001092908 WinXP. This is getting really annoying. Can anyone help or know what the problem is?

not real sure if I can fix this myself. sounds like a font metrics. I am sure I have a dup bug somewhere. putting into 9.9 until I can find the dup.

I guess I should take this. It's one of a group of bugs that are caused by the fact that we measure Arabic text before doing shaping. Bug 74929 and bug 74998 are related.

Doesn't look as if this will be ready before the freeze.

nsbeta1+ . smontagu said it is really a dup of 82352

No, that was a mistake. This is a different issue.

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

does this also happen on bidi os ?

>does this also happen on bidi os ? No, but there is another bug with selection of Arabic on Bidi systems: bug 75011

Impact Platform: ALL except bidi-window Impact language users: Arabic users using those platforms ( about 500K [Arabic in US] 0.089% of internet users out of 4.4 M of total Arabic users ) Probability of hitting the problem: HITH, every text selection of Arabic page will show the problem Severity if hit the problem in the worst case: some text will be unreadable. Way of recover after hit the problem: do not select Risk of the fix: VERY HIGH Potential benefit of fix this problem: fix other Arabic display issue

Changing summary since I the patch I attached today also fixes bug 74929 and bug 74998, and the old summary is misleading about the severity.

smontagu- not sure I understand the difference between the screenshot, I only see the following difference, are those the issue? 1. the space between the arabic text are different, the one with fix have reasonable space in between and the one without the fix have larger amount of space in between 2. the line in the sidebar below "BBC News in Arabic" have some number show up "26", "1423", "12", etc. but the one without the fix do not show those number. I thought the problem is about selection, if that is the case, you should make screenshot of selecting arabic text.

Comment on attachment 77103 [details] [diff] [review] Patch v.1 this patch looks like a collection of several issues together, please break them down into different bugs one by one. and let's have small (3- 10 lines) patch for each bugs.

Comment on attachment 77103 [details] [diff] [review] Patch v.1 this patch looks like a collection of several issues together, please break them down into different bugs one by one. and let's have small (3- 10 lines) patch for each bugs.

In the screenshots, compare: 1) The right margin of the main text. 2) The spacing, especially around English words. 3) The width of underlined text, compared to the width of the underlining. 4) The text in the sidebar above "CNN.com U.S.". The first letter is missing in the first screenshot.

Could you break them down into individual bug with smaller patch ?

This is possibly the most significant patch to Mozilla for Arabic. From the screenshot, it is EXACTLY what all the Arab speakers want, and have been harping about. PLEASE PLEASE PLEASE consider this for 1.0.

Yes! I concur with what Mohammed has said. PLEASE consider this for 1.0 once Arabic has been fixed then it will help Farsi, Urdu, Sindhi, Kashmiri and other languages using Arabic Script. Release 1.0 will get most wide circulation with Arabic fixed in that release will attract more. Thanks!

I am sure this is not created by this patch, but it would be nice to add to it. When viewing a page which has a an unordered bulleted list, the bullets show on the left side of the screen as opposed to the right where the list item actually starts. http://www.arabeyes.org/howto/wincvs/ is an example of that. I have been using a patched version since April 11th, and I have experienced no problems at all. I did not notice any slowness (with any of the xul modules), and in fact it is actually better. With 0.99 whenever you to type in a url and there is some Arabic in the history, it takes a considerable amount of time (5-15 seconds) to give you control back.. that is no longer the case with the patched version (I don't know if it has to do with the fact that the unpatched version is a nightly-built binary distro from mozilla and the other is fresh out of cvs).

I don't know if I should attach it to the bug (probably not a good idea), but I create a linux binary distribution with the patch so those who are interested in testing it out would be able to. http://arabeyes.sourceforge.net/mozilla-i686-pc-linux-gnu.tar.gz

I think this patch is too big and too risky for m1.0. It just too late in the game to accept big patch like this. I think we should land this into trunk first at least. Please got sr= first. I strongly suggest you break down the patch into different individual issues/bugs and maybe drivers@mozilla.org willing to take some small, less risky part.

mark this bug as nsbeta1-, we don't have enough time to fix this for nsbeta1 and the proposed fix is too big and risky.

I don't understand. Why is this not seen as a critical bug that would make a big difference for 1.0? Why can't 1.0 be pushed back a few days for this? It may be naive of me, but I consider this to be an _extremely_ important bug, so important that 1.0 would deserve to have it fixed. Oh well.

General comment (not wanting to isite a thread here): No one doubts the impact of this bug. There gating issue is ""bang for the buck". There are more bugs than people to fix them and choices must be made based on the affected audience. e.g. Should they fix a slow scroll or layout bug affecting all users or a specifc layout bug which affects only a subset? All things in due time -- 1.0 is not an end to Mozilla but a beginning -- fixes will follow as will new features.

lohphat, too late for that ;) I understand all of this, and I have an appreciation for it. What I am trying to drive home here is that no one here seems to realize the severity of the bug for the Arab user. Mozilla without this patch is simply not usable for Arabic. I would imagine this would impact all Arabic-based scripts as well.

>I don't understand. Why is this not seen as a critical bug that >would make a big difference for 1.0? Why? read the following page http://www.euromktg.com/globstats/ Language |Internet |%'age world |2003 (est. in M)|Total pop. (M) |access (M)|online pop. | | Arabic | 4.4| 0.8%| 6 | 300 0.8% of totla internet users is a small amount of users. >Why can't 1.0 be pushed back a few days for this? This is not a new bug, this bug was filed at 2001-09-15 16:22 and I am still not satisifed with the patch. There are no reason that that "a few days" can fix this issue. It could take "a few weeks" >I consider this to be an _extremely_ important bug I 100% agree with you that you will consider this to be an _extremely_ important bug. Not only that, 4.4M (0.8% of total internet users) will also consider this to be an _extremely_ important bug. Unfortunatelly, the rest 555.6M (99.2% of total internet users) won't consider this is an _extremely_ important bug at all. Actually, they will consider this as an not important bug at all. >Mozilla without this patch is simply not usable for Arabic. According to smontagu, there are more than ONE issue here. What I don't like is we combine several issues together in this one bug and think this is the ONE issue we need to solve. I am willing to review patches one issue at a time. Not a giant patch which deal with several issues at once like this.

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

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

batch: adding topembed per Gecko2 document http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html

is this still happening with more recent software versions? (bug cleaning)

The only outstanding issue is that Arabic text displayed by XUL doesn't go through the correct codepath, which can cause issues like, for example, the underlining of Arabic bookmarks in the personal toolbar not being the same length as the text. The big patch here in attachment 77103 [details] [diff] [review] fixes that, but that part of the patch didn't make it into any of the dependent bugs because I was worried about performance issues. I'll file a new bug on that issue, and close this one.

(In reply to comment #35) > I'll file a new bug on that issue, and close this one. ping? :-)

That would be bug 404149, so this can be closed now.