221910 - Use of RLM causes duplicate numbers in HebrewLetter+HyphenMinus+RLM+Number sequences

Status: RESOLVED DUPLICATE of bug 177442

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

Description

[Prognathous]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925

Using RLM (and LRM) is the easiest way at the moment to overcome the difference
between the Unicode BiDi algorithm and the one used commonly by other vendors
(Microsoft, Opera and others). It helps Mozilla users correct the way Gecko
(mis)handles HebrewLetter+HyphenMinus+Number sequences.

This works well with textareas, but not with single-line text fields, as a bug
in Mozilla causes duplication of the first number.

Reproducible: Always

Steps to Reproduce:
I will shortly attach a test case that shows the following:

1. RTL textarea; EnglishLetter+HyphenMinus+RLM+Number  -> OK
2. RTL textarea; HebrewLetter+HyphenMinus+RLM+Number  -> OK
3. RTL text field; EnglishLetter+HyphenMinus+RLM+Number  -> First number is
duplicated
4. RTL text field; HebrewLetter+HyphenMinus+RLM+Number  -> First number is
duplicated
5. LTR textarea; EnglishLetter+HyphenMinus+RLM+Number  -> OK
6. LTR textarea; HebrewLetter+HyphenMinus+RLM+Number  -> OK
7. LTR text field; EnglishLetter+HyphenMinus+RLM+Number  -> OK
8. LTR text field; HebrewLetter+HyphenMinus+RLM+Number  -> First number is
duplicated

Actual Results:  
See above.

Expected Results:  
Numbers should not be duplicated, regardless of control characters.

Prog.

To type an RLM in Windows, switch to Hebrew, then hold down the Alt and type
0254 using the numeric keypad.

Comment 1

[Prognathous]

Attachment: RLM Testcase

Comment 2

[Prognathous]

Note that ISO-8859-8 (Visual) does not support RLM marks. This makes it more
difficult to correct such sequences. As an alternative, it is possible to use
soft hyphens instead: HebrewLetter+HyphenMinus+SoftHyphen+Number. This could
have been a satisfactory workaround (as in most cases soft hyphens do not
display), but similarly to the RLM, it fails in Mozilla when the sequence starts
with a Hebrew letter and is in a single-line text fields.

Another upcoming attachment will show this:

1. RTL textarea; EnglishLetter+HyphenMinus+SoftHyphen+Number  -> OK
2. RTL textarea; HebrewLetter+HyphenMinus+SoftHyphen+Number  -> OK
3. RTL text field; EnglishLetter+HyphenMinus+SoftHyphen+Number  -> OK
4. RTL text field; HebrewLetter+HyphenMinus+SoftHyphen+Number  -> First number
is duplicated
5. LTR textarea; EnglishLetter+HyphenMinus+SoftHyphen+Number  -> OK
6. LTR textarea; HebrewLetter+HyphenMinus+SoftHyphen+Number  -> OK
7. LTR text field; EnglishLetter+HyphenMinus+SoftHyphen+Number  -> OK
8. LTR text field; HebrewLetter+HyphenMinus+SoftHyphen+Number  -> First number
is duplicated

To type a soft hyphen in Windows, switch to Hebrew, then hold down the Alt and
type 0173 using the numeric keypad.

It is worth mentioning that IE6 passed the above 16 tests with no problems at
all. I haven't tested it with Opera yet.

Prog.

Comment 3

[Prognathous]

Attachment: Soft Hyphen Testcase

Comment 4

[Shoshannah Forbes]

CONFIRMED with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6b)
Gecko/20031129 Firebird/0.7+

Comment 5

[Hixie (not reading bugmail)]

If this bug is about character duplication, here's a significantly simpler
testcase: http://www.hixie.ch/tests/adhoc/unicode/bidi/012.html

Comment 6

[Prognathous]

Attachment: Hixie's testcase (comment #5)

Comment 7

[Uri Bernstein]

This seems identical to bug 177442: Both describe frame duplication in <pre> (or
white-space:pre) frames when LRE/RLE markers are used.

Any reason this is not a duplicate?

Comment 8

[Uri Bernstein]

Got no answer on comment #7. Marking dependency for now.

Comment 9

[Uri Bernstein]

(In reply to comment #3)
> Created an attachment (id=133118) [edit]
> Soft Hyphen Testcase

I'm not seeing any number duplication in this case. What I am seeing is that the
soft hyphen is sometimes displayed - I filed this as bug 312063. Is this what
you meant, or do you (did you) actually see duplicated numbers in this testcase?

Comment 10

[Prognathous]

It is still possible to reproduce the RLM problem with the latest Firefox trunk
(20051012/1.6a1), but the soft-hypen testcase seems ok.

I don't see how this is a dupe of bug 177442 which doesn't even mention RLMs nor
soft-hypens.

Prog.

Comment 11

[Prognathous]

Since bug 73251 is fixed, this one no longer has much real-life impact (not that
many users besides me ever used RLMs or hypen-minus to workaround the
HebrewLetter+HyphenMinus+Number issue). It is possible that some people would
still want to use RLM in single-line input fields, but it's not a very common
need. I'd say move on to more interesting/important bugs, let this one rest.

Prog.

Comment 12

[Uri Bernstein]

(In reply to comment #10)
> It is still possible to reproduce the RLM problem with the latest Firefox trunk
> (20051012/1.6a1), but the soft-hypen testcase seems ok.
> 
> I don't see how this is a dupe of bug 177442 which doesn't even mention RLMs nor
> soft-hypens.

Bug 17742 uses RLOs and LROs, not RLMs and LRMs, but I suspect it's pretty much
the same. As for soft hyphens - they're no longer an issue, so it's likely they
had little to do with this bug in the first place.

Comment 13

[Danny Sadinoff]

I just hit this myself.  In theory LRM seems like a good way out of BIDI confusion, but when you try it, Firefox makes things worse.  

This could be construed as a documentation issue: if LRMs are not the right way to fix some difficult bidi text, perhaps we should document what is.  Overrides? etc.

Comment 14

[Uri Bernstein]

The fix to bug 333769 fixed this, proving that this was indeed a duplicate of bug 177442.

*** This bug has been marked as a duplicate of 177442 ***