152148 - LTR text incorrectly appears as RTL (inlines with dir="ltr" on Visual Hebrew pages)

Status: REOPENED

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

Description

[Shoshannah Forbes]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530
BuildID:    20022053012 (moz 1.0)

The attached page was created using word, with a mess of CSS. All the english
text in the page appears as RTL, althugh it has <span dir=ltr> wrapping it.
For some reason, attempting to create a simplified text case does give the full
results- so I suspect that something in the interaction of that full page is
giving use this mess

Reproducible: Always
Steps to Reproduce:
1. go to above url


Actual Results:  the english text appear reversed

Expected Results:  should display ok

it is difficult to create a simplified test case for this page, since view
source opens inside mozilla (which is not easy to work with for editing text) on
one hand (bug  35268 and bug 35268) and copy/paste is dificult since I am unable
to select multiple lines (bug 82352 ).
Once those two bugs would be fixed, it will make it *much* easier to isolate
bugs like on this page.

Comment 1

[Nicholas Allen]

WFM Win2k 20020614 trunk

I see the main text going RTL and all the embedded English text going LTR.

Comment 2

[Simon Montagu :smontagu]

There is no charset declared in the page. If you select ISO-8859-8 (manually or
as default charset) it displays as Shosh describes. If you select ISO-8859-8-I
it displays correctly.

Comment 3

[Shoshannah Forbes]

Did some more testing:
It seems like whenthe browser default is set to visual Hebrew, and a Hebrew page
has no charset declaration, Roman text is displayed RTL.
I am getting this with build 2002061603 on OSX as well.

Simple example:
* set your default charset to visual Hebrew.
* Go to this page:
http://bugzilla.mozilla.org/attachment.cgi?id=46897&action=view
See the English text appear as RTL.

Comment 4

[Simon Montagu :smontagu]

I think this is INVALID. Visual means "no reordering". If dir=ltr, then
everything is left-to-right, including Hebrew; if dir=rtl, then everything is
right-to-left, including ENGLISH.

Comment 5

[Shoshannah Forbes]

The original page i filed the bug against is actully logical- but missing a
charset declaration, so it was using my deafult (visual). However, the  Hebrew
parts are sorrunded with dir=rtl, and the english parts with dir=ltr.
When using my default, the dir=ltr got ingnored.

Comment 6

[Simon Montagu :smontagu]

Now I get it. You expect that inline elements in a visual page should change
direction according to the dir attribute.

The team at IBM who implemented Bidi considered this and decided that on visual
pages the dir attribute would only take effect at the block level - e.g. you
could have two paragraphs in different directions by using <p dir="rtl"> and <p
dir="ltr"> - but not at the inline level.

Is there an example of a real-world visual page which will break with our
current behaviour? If the problem only arises in artificial circumstances and
can be corrected by changing encoding (or changing from viusal to logical when
we have a UI to do so), then this is still INVALID, or at least WONTFIX.

Comment 7

[Shoshannah Forbes]

*** Bug 222606 has been marked as a duplicate of this bug. ***

Comment 8

[Asaf Romano (gone)]

(In reply to comment #6)

> Is there an example of a real-world visual page which will break with our
> current behaviour? If the problem only arises in artificial circumstances and
> can be corrected by changing encoding (or changing from viusal to logical when
> we have a UI to do so), then this is still INVALID, or at least WONTFIX.

http://www.cameri.co.il/mg/tickets.asp (second line)

Comment 9

[Eyal Rozenberg]

Not seeing any English text reversed at http://www.avi.org.il/  ...

Comment 11

[(no longer active)]

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

Comment 12

[James Little]

In Firefox 2.0.0.15 on Windows and Linux, I am seeing ltr content being reversed in text areas and in source code after Hebrew characters. 

This doesn't seem to happen with Arabic characters.

Comment 13

[Simon Montagu :smontagu]

I can't seem to reproduce that. Can you point to a specific site where you are seeing it?

Comment 14

[James Little]

(In reply to comment #13)
> I can't seem to reproduce that. Can you point to a specific site where you are
> seeing it?
> 
It might be related to a special character? 

The source of this document http://nzfusion.com/james/hebrew_firefox.html appears the same in Gedit, which I used to create the document.

Comment 15

[Simon Montagu :smontagu]

You're right about the special character. The line <h3>בית</h3> has a U+202E RIGHT-TO-LEFT OVERRIDE character at the beginning of the Hebrew text (I've addded a U+202C POP DIRECTIONAL FORMAT after it when pasting into here, otherwise all of this comment would be oot sdrawkcab)

Comment 16

[Mardeg]

I'm wondering if this is the bug being hit by the project at https://github.com/lwt-project/lwt which is using LTR mixed with RTL in modified overlib ( http://www.bosrup.com/web/overlib/ ) tooltips.
Is a U+202E RIGHT-TO-LEFT OVERRIDE character involved in stopping the ▶ line from being LTR? Screenshot of the problem:
http://imgh.us/RTL-in-tooltip.png
which should look like:
http://lwt.sourceforge.net/img/26.jpg

(because of either old js or the Learning with Texts project uses textareas in frames the tooltips may not always appear if you're testing)