BuildID: 2001051120 Multiline Arabic text cannot be selected. The selection jumps in a weird way. Reproducible: Always Steps to Reproduce: 1. Open an Arabic page, such as 'http://www.persianacademy.ir/' or 'http://www.ayna.com/'. 2. Click on the middle of some Arabic text. Keep the mouse button down, and move to the next Arabic line.

Changing QA contact to mahar@eg.ibm.com

confirming

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

Mass-move all BiDi Hebrew and Arabic qa to me, zach@zachlipton.com. Thank you Gilad for your service to this component, and best of luck to you in the future. Sholom.

QA to mahar.

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

I see this bug as well, at http://oketz.com (Hebrew). Reproduce by selecting a section of text on one line, and moving the mouse up or down: the selection is cancelled and a new one is started in the mouse position on the line above or below. This should probably be major severity for BiDi...

0.9.6 Win32 On http://chanae.stben.be/pablo/hello.html I cant select multiple lines of text that is ltr but in different encoding. Or perhaps it is caused by the fact that rtl text exist on the same page?

Yes, as soon as there is right-to-left text anywhere on the page, the bidiEnabled flag is set for the whole document, so this bug will appear.

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

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

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

Taking

nsbeta1+ per triage meeting

Impact Summery Impact Platform: ALL Impact language users: Arabic and Hebrew . total 6.3 M 1.125% of total internet users Probability of hitting the problem: HIGH, every text selection of Arabic/Hebrew 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/Hebrew display issue

actaully, this bug is more visible then mentioned above, since it is in the composer and mail/news as well, those preventing rather basic editing of bidi text (like trimming posts in email replays....)

>Risk of the fix: VERY HIGH sorry, I have to back up that line. I cannot tell without a patch. IT should be Risk of the fix: TBD

IT is too late to deal with this issue now. mark it as nsbeta1- so smontagu can focus on crash/hang issues.

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

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

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

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

As xslf@yahoo.com writes in comment 16, this bug also occurs in e-mail composition (with severe implications). But worse yet, the effect there is persistent: once the mail/news editor sees some bidi text, multiline selection breaks *and remains broken until you restart Mozilla*. Just closing the message and opening a new one does not reset things. This enables a simple DoS attack -- by causing you to reply to an e-mail containing bidi HTML, anyone can cause your Mozilla to become dysfunctional regardless of your locale.

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

Like most bugs involving stupid typos, this took FAR too long to track down.

Has the patch been used in Mozilla 1.1? If not how can I apply the patch myself?

Comment on attachment 96738 [details] [diff] [review] Patch ya! i am glad this is fixed. r=mjudge

Comment on attachment 96738 [details] [diff] [review] Patch sr=bzbarsky

Fix checked in.

The fix is not in Mozilla 1.1, but it will be in 1.2 and already is in the nightly builds at ftp.mozilla.org/pub/mozilla/nightly/latest/

The new marking patch works good in the last nighly (good work, guys!), but has one major problem. If the text marker goes outside of the currect HTML element, the marking direction goes LTR. Here is the source file I have used, next I'll attach a screenshots. --- 8< --- CUT HERE --- 8< --- <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"> <html dir="rtl"> <head> <meta http-equiv="Content-Type" content= "text/html; charset=ISO-8859-8-i"> <title></title> </head> <body> <p>גנן גידל דגן בגן,<br> דגן גדול גדל בגן.</p> <p>שרה שרה שיר שמח,<br> שיר שמח שרה שרה.</p> </body> </html> --- 8< --- CUT HERE --- 8< --- Should I open new bug for this, or this bug has to be re-opened?

Remaining problems with bidi selection belong in bug 76190 as things currently stand, but look out for changes. I have just attached a patch there to convert Mozilla's bidi selection from visual selection to logical selection, and if that gets checked in, I will file a new bug (targetted to Future) for fixing and reimplementing visual selection.

Comment on attachment 96738 [details] [diff] [review] Patch Risk appears minimal though there are more BIDI selection issues as mentioned in the other bug. a=rjesup@wgate.com for 1.0 branch. Please change mozilla1.0.2+ to fixed1.0.2 when checked in. Please checkin ASAP to make 1.0.2

Do we even need to check this in to the branch? The code modified here was #ifdef'd out by the checkin to bug 76190.

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

Removing myself from the CCs