Characters are inserted at the wrong place in text effected by direction override (LRO/RLO)

RESOLVED DUPLICATE of bug 289857

Status

()

defect
RESOLVED DUPLICATE of bug 289857
15 years ago
11 years ago

People

(Reporter: sashash, Assigned: mkaply)

Tracking

({rtl})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040316
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040316

Use textarea element having LTR/RTL marker at 0 position.

The position where characters gets inserted when typing is incorrect(is one
position to the left from visible position of caret).

Reproducible: Always
Steps to Reproduce:
1. Use textarea element having LTR/RTL marker at 0 position as follows:
<textarea>&#8237;abcdef</textarea>

2. Set cursor between characters 'b' and 'c'.

3. Type in character '1'.
Actual Results:  
The character '1' been typed in step 3 gets inserted between "a' and 'b'.

Expected Results:  
The character '1' should be inserted at current caret position between
characters 'b' and 'c'.
Confirmed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040514

I'm rephrasing the summary to make it clearer and lowering the Severity to Normal.

Testcase coming.

Prog.
Severity: major → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: When typing into textarea having LTR/RTL marker at 6the first place, characters gets inserted at wrong place. → Characters are inserted at the wrong place in text effected by direction override (LRO/RLO)
Posted file Testcase
The attached testcase shows several textareas effected by RLO and LRO (both
with and without a closing PDF). In all of them, trying to insert characters
displays the bug.

Additionally, RLO doesn't override LTR text as it should (try to compare with
IE6). Is this a known bug?

Prog.
We are currently working on Bidi enablement of HATs6 product.
One of our primary goals is to make it available for LINUX users basing on 
Mozilla browser.
The HATS provides the end users with Web simulation of legacy systems (such as 
mainframe and as400) which maintain the visual presentation of Bidi characters.
So we are compelled to use LRM/RLM markers to disable Bidi reordering.
This defect handicaps us from doing that.

PS. The prefferable solution for our problem would be enabling "bidi override 
styles" for textarea.
That style (as follows) style="direction: rtl; unicode-bidi: bidi-override"
works for all elements of DHTML and also for DOM elements
except textarea and input.
The code implementing impact of bidi override styles on Mozilla inputs has been
provided by us a few years ago but apparently has been dropped by some reaseon.
Blocks: 115711
(In reply to comment #3)
> The code implementing impact of bidi override styles on Mozilla inputs has been
> provided by us a few years ago but apparently has been dropped by some reaseon.

Do you have any record about the number of this bug?

Prog.
We do not supplied this code under any bug number.
This was the initial code contribution in early version of Mozilla that
contained the code related to Bidi override styles support.
Sasha, there is an option to use visual ordering in text fields on visual pages.
If you set the pref "bidi.controlstextmode" to 3, you should get the results you
expect.
Depends on: 177442
This WFM on OS X since the 2005-04-26 build (but I can reproduce the bug in
builds from 2005-04-19 and before. I can't find Mac builds in between).

Can someone perhaps:
- Verify that it is currently WFM (on Windows)
- Pinpoint where it was fixed and find candidate patches which might have fixed it
 
OS: Windows 2000 → All
Hardware: PC → All
My suspect for fixing this is the patch to bug 289857 (checked in 2005-04-21
18:30 PDT).
That sounds reasonable to me. Marking dupe.
(In reply to comment #2)

> Additionally, RLO doesn't override LTR text as it should (try to compare with
> IE6). Is this a known bug?

That was bug 177148, also now fixed.

*** This bug has been marked as a duplicate of 289857 ***
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: zach → layout.fonts-and-text
You need to log in before you can comment on or make changes to this bug.