Closed Bug 82352 Opened 23 years ago Closed 22 years ago

Cannot select multiple lines of right-to-left text

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla1.0

People

(Reporter: roozbeh, Assigned: smontagu)

References

()

Details

(Keywords: intl, topembed, Whiteboard: [adt2])

Attachments

(3 files)

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
QA Contact: andreasb → mahar
confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: Internationalization → BiDi Hebrew & Arabic
*** Bug 92044 has been marked as a duplicate of this bug. ***
OS: Windows 2000 → All
Hardware: PC → All
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 Contact: mahar → zach
QA to mahar.
QA Contact: zach → 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...
Severity: normal → major
Summary: Bidi: Cannot select multiline Arabic text → Cannot select multiple lines of right-to-left text
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.
Blocks: 115709
*** Bug 118084 has been marked as a duplicate of this bug. ***
*** Bug 119289 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1
*** Bug 123208 has been marked as a duplicate of this bug. ***
Taking
Assignee: mkaply → smontagu
nsbeta1+ per triage meeting
Keywords: nsbeta1nsbeta1+
Status: NEW → ASSIGNED
Priority: -- → P2
Whiteboard: adt2
Target Milestone: --- → mozilla1.0
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
Keywords: intl
Whiteboard: adt2 → [adt2]
IT is too late to deal with this issue now. mark it as nsbeta1- so smontagu can
focus on crash/hang issues. 
Keywords: nsbeta1+nsbeta1-
*** Bug 141963 has been marked as a duplicate of this bug. ***
*** Bug 127515 has been marked as a duplicate of this bug. ***
Attached file Minimized testcase
*** Bug 112101 has been marked as a duplicate of this bug. ***
*** Bug 145997 has been marked as a duplicate of this bug. ***
Blocks: 152111
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. ***
Keywords: mozilla1.0.2
Attached patch PatchSplinter Review
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
Attachment #96738 - Flags: review+
Comment on attachment 96738 [details] [diff] [review]
Patch

sr=bzbarsky
Attachment #96738 - Flags: superreview+
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
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
Attachment #96738 - Flags: approval+
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
Keywords: topembed
Blocks: grouper
Removing myself from the CCs
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: mahar → layout.fonts-and-text
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: