98073 - Search of Hebrew text in visual Hebrew page looks for reversed text.

Status: NEW

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

Description

[Ilya Tsindlekht]

When searching page in visual Hebrew for hebrew text, mozilla finds text which
is reversed version of the text I enter in 'Find' dialog. Search in logical
Hebrew page works as expected.

Comment 1

[Shoshannah Forbes]

Since the source in Visual pages is reversed, isn't that the correct behavier?
/me wishes the windows builds wwould also do that.

Comment 2

[Ilya Tsindlekht]

When user searches, he/she searches the text he reads, not its source, so the
correct behavior is to match text with text.

Comment 3

[Shoshannah Forbes]

>When user searches, he/she searches the text he reads, not its source

Exacly. and in order to match what the user reads, Mozilla should search the
source in visual pages backwords. Otherwise, it won't find anything.

For example, in a visual page, a user would search for ωμεν
However, no such string exsists in the source. If you want to match what the
user reads, you should search for νεμω in the source.
After all, most users don't even know if the page they are at is visual or
logical, and even less what is the diffrence, and how to type the search term
backwords to get the correct resoults.

Again- IMHO, linux builds get it right, windows builds do not

Comment 4

[Simon Montagu :smontagu]

Ilya and Shoshannah: I think the two of you are at cross-purposes.

If I spell out the expected behaviour laboriously, I think you will find you
both agree.

(i)   To find a text in a Hebrew page, the user opens the find dialog and types
the search string in normal logical order. 

(ii)  The search string appears in the dialog box in normal visual order. 

(iii) In a logical page, Mozilla searches for the search string as is. 

(iv)  In a visual page, Mozilla searches for the string formed by applying the
Unicode Bidi Algorithm to the search string.

AFAIK, in all builds the actual behaviour is (i) (ii) and (iii) but not (iv).

Comment 5

[Shoshannah Forbes]

I am not sure what you mean in
"(ii)  The search string appears in the dialog box in normal visual order" ?
IIRC, the input widgets should always be logical (see bug 82849). Or am I just
brain-dead this morning?

Comment 6

[Simon Montagu :smontagu]

What I mean is simply the behaviour that you intuitively expect: that Hebrew and
Arabic text should be displayed from right to left and English and numerals from
left to right; in other words that bidirectional text entry is reordered before
display.

Comment 7

[Ilya Tsindlekht]

I think I and Shoshanah want the same thing. Simon Montagu's summary is correct.

Comment 8

[Shoshannah Forbes]

<aol>
Me 2!
</aol>

So, what is our next step? Open a seprate bug about iv?

Comment 9

[Simon Montagu :smontagu]

Why a separate bug? If Mozilla did (iv), this bug would be fixed, no?

Comment 10

[Keyser Sose]

Marking these all WORKSFORME sorry about lack of response but were very
overloaded here. Only reopen the bug if you can reproduce with the following steps:

1) Download the latest nightly (or 0.9.6 which should be out RSN)
2) Create a new profile
3) test the bug again

If it still occurs go ahead and reopen the bug. Again sorry about no response
were quite overloaded here and understaffed.

Comment 11

[Simon Montagu :smontagu]

Bug reproduced with new profile on today's build

Comment 12

[Christopher Hoess (gone)]

confirming.

Comment 13

[Simon Montagu :smontagu]

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

Comment 14

[Hixie (not reading bugmail)]

How do we know if a page is in visual order?

Comment 15

[Simon Montagu :smontagu]

>How do we know if a page is in visual order?

We generally assume that it is sufficient to use the document charset as an
indication of the ordering, but this assumption has problems. There is nothing
to stop a content author creating a visual document by using <BDO> elements, and
the HTML spec even seems to recommend this as a technique for making visual
documents conformant. http://www.w3.org/TR/html4/struct/dirlang.html#bidi88598

Comment 16

[Hixie (not reading bugmail)]

So basically we have no way of doing this?

Comment 17

[Simon Montagu :smontagu]

Maybe somebody cleverer than I am can come up with something, but I can't think
of a foolproof solution.

Comment 18

[timeless]

> i'd like to know how visual (and? logical) text is stored in dom
< timeless: that would involve some weird hackery.   moz<bdo>alli</bdo>
< should that find "mozilla"?
> yes it should :). if i see it, i should be able to search for it. (of course,
um, that's not always reasonable. if someone absolutely positions a string of
characters in random order so that there is no sane way to search then ...)

Comment 19

[Simon Montagu :smontagu]

>if i see it, i should be able to search for it.

Just as an example of what this might involve, imagine searching for "ABCDEFGHI"
on http://www.people.fas.harvard.edu/~dbaron/css/test/bidi2

Comment 20

[Hixie (not reading bugmail)]

I'm thinking we should WONTFIX this unless someone can think of a reasonable
algorithm for it. The root of the problem is that bidi overrides don't mean the
same thing in logical documents as in visual documents. Or something. This bug
makes my head spin... :-/

Comment 21

[Prognathous]

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

Comment 22

[Haggai Eran]

I suggest that firefox will just use the character set to determine if the page
is visual or logical. This is only a partial solution ofcourse, but most of the
visual Hebrew sites I know are written this way (with charset=iso8859-8) and
this would improve the functionality on these sites. It is better than leaving
this as it is - right now the user have to know if the site is visual, and type
backwords.