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

Status: RESOLVED DUPLICATE of bug 289857

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

Description

[Alexander Shensis]

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'.

Comment 1

[Prognathous]

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.

Comment 2

[Prognathous]

Attachment: 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.

Comment 3

[Alexander Shensis]

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.

Comment 4

[Prognathous]

(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.

Comment 5

[Alexander Shensis]

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.

Comment 6

[Simon Montagu :smontagu]

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.

Comment 7

[Uri Bernstein]

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
 

Comment 8

[Uri Bernstein]

My suspect for fixing this is the patch to bug 289857 (checked in 2005-04-21
18:30 PDT).

Comment 9

[Simon Montagu :smontagu]

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 ***

Comment 10

[(no longer active)]

Mass-assigning the new rtl keyword to RTL-related (see bug 349193).