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.

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 .

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

Nothing has been happening on the beos side for a while, closing.