Closed Bug 230080 Opened 16 years ago Closed Last year

BeOS: Wrong directional caret in Hebrew editing (LTR bidi marker instead of RTL)

Categories

(Core Graveyard :: Widget: BeOS, defect)

Other
BeOS
defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: bugzillamozilla, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: helpwanted, intl, rtl)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.7a) Gecko/20040104
Build Identifier: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.7a) Gecko/20040104

When typing Hebrew, the direction of the caret is left-to-right, as if the
currently selected input language is English. 

Reproducible: Always

Steps to Reproduce:
1. Switch to Hebrew keyboard layout.
2. In an RTL textarea, type a few Hebrew characters

Actual Results:  
The caret is LTR (points to the right instead of to the left)

Expected Results:  
The caret should be RTL, or at least non-directional.

For easier language switching and entry of Hebrew, the following add-ons are
recommended:
Switcher - http://bebits.com/app/233
International Keymap Pack - http://bebits.com/app/698
What is RTL area? Where can i try it? Is this special forms on hebrew web pages?
The attached file shows an RTL textarea, as commonly used in Hebrew and Arabic
pages.

Sergei, type a few characters using a Hebrew keyboard layout, and you'll see
that besides the wrong caret-direction, Mozilla handles this textarea fairly
well - it's both right-aligned and has the correct paragraph direction
(right-to-left).

Prog.
This problem also appears on OS X (rv1.5, 10.2.8), but to a far less obvious
extent. If the user zooms the page to 300%, it is possible to see that the caret
does have some slight LTR direction of a pixel or so, but it's not as evident as
with the directional caret in Windows (supported OS feature) or BeOS (out of place).

Prog.
I see. This behaviour reminds me old BIDI editors. Is this BeZilla-only issue?
As far i understand, this BIDI-handling happens ouside BeOS-specific modules,
even caret isn't "beos-native".
Though, maybe we lack some method and/or, for example, option in
widget/src/beos/nsLookAndFeel.*
CCing smontagu, as he may have the answer for comment #4

Prog.
What we need is a BeOS implementation of the Bidi keyboard widget, specifically
nsBidiKeyboard::IsLangRTL, which is currently stubbed out in
http://lxr.mozilla.org/seamonkey/source/widget/src/beos/nsBidiKeyboard.cpp.

Currently the only implementation of that method is in the Windows version, and
it's not very elegant. We use GetKeyboardLayout() to return the current input
locale identifier at
http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsBidiKeyboard.cpp#77
and then compare the language identifier, which is extracted from the locale
identifier by the PRIMARYLANGID macro, to a hard-coded list of right-to-left
languages at
http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsBidiKeyboard.cpp#192
Simon,
we don't have in BeOS OS-wide locale (yet).
And any existing method to switch keymaps don't set it.

Though, as BeOS keyboard passes utf-8 values to applications, we can test that
input for Unicode Block. But i don't think it is good idea to have such "filter"
as deafult - it will slowdown already not-so-responsive keyboard input in BeZilla.
Also, problem is that there are several Unicode Blocks for some languages. It
add's some load to that input checker.
Prognathous,
i tried your attachment, and i see bold vertical line as caret, which is placed
on left side of hebrew symbols, but if i type non-hebrew symbol, it appears on
right side of typed symbol.
What's wrong with that behaviour?
Sergei, the problem is not with the position of the caret, but rather with its
direction pointer. The latter is a small chunk of pixels at the top of the
caret, that points to the right or to the left, depending on the currently
selected keyboard layout (this is unfortunately always LTR in non-Windows
builds). See screenshots of Mozilla/Win vs. the OS X and BeOS builds -
http://oren.gomen.org/mozilla/beos/bug_230080

BTW, you're right, /boot/preferences/Keymap does not respond to keyboard layout
changes using Switcher - and vice versa. So there's probably no way to retrieve
the keyboard layout in-use.

Simon, both BeOS and OS X do not implement directional caret, but on the Mac,
the caret looks almost directionless. Is this configurable? at least on
platforms where directional caret is not implemented, this can be a good compromise.

Prog.
Prog,
this is very interesting situation in such case.
It means that mozilla knows, which type of character is entered, RTL or RLT.
No need for input filter mentioned in my previous post or system locale.
And caret form in BeZilla is definitely predicted outside of any BeOS-dependent
layer. But has wrong form inspite that knowledge.

It means, IMHO, that some little thing or setting or definition is missing.
That's simple logic, but honestly, i don't understand in reality, which parts of
Mozilla are responisble for those tasks, so maybe i am wrong
Prognathous: the images in your testcase will display better if you write "%25"
in the URIs, not just "%"

It should be simple enough to add something like eMetricShowDirectionalCaret to
nsILookAndFeel, and not show any directional indication if we can't know the
direction of the keyboard language, but I'm not 100% sure that we can't manage
something even in BeOS, in spite of what Sergei says. The indication isn't
expected to be 100% reliable, just a hint. There will always be the possibility
of inserting an LTR character from a "RTL" keyboard.

The fact that the directional indication is almost invisible on Mac is just a
bug, maybe a rounding error causing it to have zero width instead of 1 pixel
some of the time.
Simon Montagu wrote:
> The fact that the directional indication is almost invisible on Mac is just a
> bug, maybe a rounding error causing it to have zero width instead of 1 pixel
> some of the time.

Is Mozilla always supposed to use a BiDi marker? for example, see Bug 98157
("Caret does not have bidi marker in certain dialog boxes"). Is this something
than can be intentionally applied to non-Windows builds, such as the one for
BeOS? it's better to have no BiDi marker at all, than to have the wrong one.

Prog.
Blocks: 115711
Summary: BeOS: Wrong directional caret in Hebrew editing (LTR instead of RTL) → BeOS: Wrong directional caret in Hebrew editing (LTR bidi marker instead of RTL)
Blocks: BidiCaret
I see this on Linux as well.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Firefox/1.0.4

So shouldn't this bug be for All OSes?

However, most of you in these bugs are concerned with displaying keyboard layout
direction.
I think the direction of written text, while placing a caret inside it or
navigating through it, also should be shown regardless of the current keyboard
layout.

For example:
1. Put some LTR text inside an LTR textbox.
2. Put some RTL text in between the LTR text.
3. Navigate the caret through the text with arrow keys.

The caret should change as the direction of text it goes through changes
regardless of the current keyboard layout.
(In reply to Alexey Chernyak, comment #13)
> I see this on Linux as well.

Indeed. See Bug 203671 ("Keyboard direction is never detected on GTK")

> So shouldn't this bug be for All OSes?

One is already there. See meta Bug 272096 ("Disable bidi caret on platforms
without nsBidiKeyboard::IsLangRTL impl'")

> However, most of you in these bugs are concerned with displaying keyboard layout
> direction.
> I think the direction of written text, while placing a caret inside it or
> navigating through it, also should be shown regardless of the current keyboard
> layout.

Hmmm... no. The whole point of the bidi caret is to provide a visual cue for
users before they start typing using the wrong language.

> The caret should change as the direction of text it goes through changes
> regardless of the current keyboard layout.

This extremly annoying "feature" was removed in Mozilla 1.6. Good riddance. From
the patch:

+  /* This implementation of automatic keyboard layout switching was too buggy
to be useful
+     and the feature itself was inconsistent with Windows. See Bug 162242 */

Prog.
Help needed to implement http://developer.mozilla.org/en/docs/nsIBidiKeyboard for BeOS.  As bug 272096 has been fixed, you won't see a Bidi Caret at all, until someone implements widget/src/beos/nsIBidiKeyboard .
Assignee: mozilla → nobody
Component: Layout: BiDi Hebrew & Arabic → Widget: BeOS
Keywords: helpwanted, intl
QA Contact: zach → behnam
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl
QA Contact: bugs+behnam → beos
Product: Core → Core Graveyard
Nothing has been happening on the beos side for a while, closing.
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.