Cannot select multiple lines of right-to-left text

RESOLVED FIXED in mozilla1.0



18 years ago
10 years ago


(Reporter: roozbeh, Assigned: smontagu)


({intl, topembed})

intl, topembed
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [adt2], URL)


(3 attachments)



18 years ago
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 ''
or ''.
2. Click on the middle of some Arabic text. Keep the mouse button
down, and move to the next Arabic line.

Comment 1

18 years ago
Changing QA contact to
QA Contact: andreasb → mahar

Comment 2

17 years ago
Ever confirmed: true


17 years ago
Component: Internationalization → BiDi Hebrew & Arabic

Comment 3

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


17 years ago
OS: Windows 2000 → All
Hardware: PC → All

Comment 4

17 years ago
Mass-move all BiDi Hebrew and Arabic qa to me, 
Thank you Gilad for your service to this component, and best of luck to you 
in the future.

QA Contact: mahar → zach

Comment 5

17 years ago
QA to mahar.
QA Contact: zach → mahar

Comment 6

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

Comment 7

17 years ago
I see this bug as well, at (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 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?

Comment 9

17 years ago
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.


17 years ago
Blocks: 115709

Comment 10

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

Comment 11

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


17 years ago
Keywords: nsbeta1

Comment 12

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

Comment 13

17 years ago
Assignee: mkaply → smontagu

Comment 14

17 years ago
nsbeta1+ per triage meeting
Keywords: nsbeta1 → nsbeta1+


17 years ago


17 years ago
Priority: -- → P2
Whiteboard: adt2
Target Milestone: --- → mozilla1.0

Comment 15

17 years ago
Impact Summery
Impact Platform: ALL
Impact language users: Arabic and Hebrew . total 6.3 M 1.125% of total internet
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

Comment 16

17 years ago
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....)

Comment 17

17 years ago
>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


17 years ago
Keywords: intl
Whiteboard: adt2 → [adt2]

Comment 18

17 years ago
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-

Comment 19

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

Comment 20

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

Comment 21

17 years ago
Created attachment 83334 [details]
Minimized testcase

Comment 22

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

Comment 23

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


16 years ago
Blocks: 152111

Comment 24

16 years ago
As 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.

Comment 25

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


16 years ago
Blocks: 154625


16 years ago
Keywords: mozilla1.0.2

Comment 26

16 years ago
Created attachment 96738 [details] [diff] [review]

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

Comment 27

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

Comment 28

16 years ago
Comment on attachment 96738 [details] [diff] [review]

ya! i am glad this is fixed.  r=mjudge
Attachment #96738 - Flags: review+

Comment 30

16 years ago
Fix checked in.
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 31

16 years ago
The fix is not in Mozilla 1.1, but it will be in 1.2 and already is in the
nightly builds at

Comment 32

16 years ago
Created attachment 97551 [details]
multiple elements testcase

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">
    <meta http-equiv="Content-Type" content=
    "text/html; charset=ISO-8859-8-i">

    <p>גנן גידל דגן בגן,<br>
    דגן גדול גדל בגן.</p>

    <p>שרה שרה שיר שמח,<br>
    שיר שמח שרה שרה.</p>
--- 8< --- CUT HERE --- 8< ---

Should I open new bug for this, or this bug has to be re-opened?

Comment 33

16 years ago
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]

Risk appears minimal though there are more BIDI selection issues as mentioned
in the other bug. 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+


16 years ago
Keywords: mozilla1.0.2 → mozilla1.0.2+

Comment 35

16 years ago
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.

Comment 36

16 years ago
batch: adding topembed per Gecko2 document
Keywords: topembed


16 years ago
Blocks: 176349

Comment 37

16 years ago
Removing myself from the CCs


10 years ago
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.