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