Input widgets on visual pages follow the visual logics. e.g. LTR input widgets won't have the RTL languages reversed, while RTL input widgets would also reverse LTR strings. While logics suggest input fields on Visual BiDi sites should follow the rendering logics for regular HTML, in real-life people always want a logical input mode. In fact, site designers expect it to be so, since on Hebrew-enabled systems such as Windows, the native widgets are always logical, and Netscape 4 / IE embeds those.

I'm going to confirm this bug tentatively. It seems that what Ilya is describing is what the default setting is. Ilya, 1. Please tell us what day's build you used and 2. if you built from the source and if you see bidi menu options on your build.

This seem to be a general issue affecting both Hebrew and Arabic. Changing QA contact to mahar. Question: Would the menu option for "a text mode in controls" be effective for form input widgets as well? If so, would that be good enough without changing the current default behavior?

The following are the possible pref settings for controls mode: Controls Text Mode 1 = logicalcontrolstextmodeBidiCmd 2 = visiualcontrolstextmodeBidi 3 = containercontrolstextmodeBidi * The default is 1. Could you please try setting these values different in your prefs.js and see how it affects this? For example user_pref("bidi.controlstextmode", 2);

Adding Gilad to the CC line.

Mike's solution (bidi.controlstextmode) doesn't seem to resolve the problem in either mode 1, 2 or 3. The page I'm testing this on is: http://test.haaretz.co.il/hasite/objects/pages/Responce.jhtml;$sessionid$Z0MNX1IAABPR3LAUAUCSF3VMCQCQMI5G It is visual and contains few DIR=RTLed input fields. Try entering mixed up text there, e.g.: SHALOM hello

It seems that setting Bidi prefs in prefs.js does not work (tried it for more than one option with no results).

Since none of the code for handling bidi preferences is checked in, there is no reason to expect setting prefs manually in prefs.js to have any effect. We should go through and rewrite the pref-dependent code so that it uses the defaults when no values are set for the bidi prefs, or when it fails to retrieve them.

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

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

Added dependency on having Bidi UI

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

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

Mass-move all BiDi Hebrew and Arabic qa to me, zach@zachlipton.com. Thank you Gilad for your service to this component, and best of luck to you in the future. Sholom.

win98 hebrew enabled / Mozilla 2001083103 Not sure if it is part of this bug, or something else: In textare form at visual pages, entering Hebrew is OK, but English is backwards. Also, text-selection using a mouse in a textarea at a visual page is completely broken. For example, type a few words in hebrew here: http://www.fisheye.co.il/reply.php3?id=549&rep=-1&LastView=2001-09-04%2015%3A17%3A07 Then click in the before the last word, to change the insert point, and add more text. Resoult: Text is added in wrong place. attempting to select text in the textarea across multiple lines give stange and unexcpected resoults.

Shoshannah, the first part of the bug you're describing is indeed the issue discussed here. I assume the input fields on fisheye.co.il are marked with DIR=RTL, and being a Visual Hebrew implies DIR=RTL reverses all text (regardless of language) to go right-to-left.

what is going on with this bug? When would we get a fix? Not to nag or anything- just that many many sites are broken due to this bug (see for example bug 84164 and bug 99572 ). Yes, some of the sites broken have other problems as well, but how can we get them to fix there side, if we can't get what should be OK working? As I noted at another place, this whole situation is rather ironic, since many sites use visual hebrew in the first place in order to be compatible with Mozilla (while visual Hebrew is non-standard compaliant and has many problems)

This bug is listed as dependent on bug 85420 (Bidi UI), but since the default setting is what is needed here, checking in mkaply's patches in bug 88100 will be sufficient. Those patches have r= from me, and only need sr= to be checked in.

This bug has indeed been fixed by the checkin for bug 88100.

I still have to enter Hebrew backwards at http://www8.huji.ac.il/shnaton/new/search_frameset.html when using build 2001110821 on Linux

I see that the text in the dropdown specifying the academic year is also backwards at http://www8.huji.ac.il/shnaton/new/search_frameset.html on Linux, but there are other visual-Hebrew sites where text in dropdowns is in the correct order, e.g http://www.israrail.org.il/israrail/doa_iis.dll/train_screen.TrainStart This may be a frameset issue. I'll investigate it further.

bumped in to this today with the nightly build from Jan 25 on OSX: when pasting Hebrew text into form (since I can not type Hebrew on OSX, see bug #120334 ) if the web page is visual, the text pasted into the form appears revesed (althugh it sends OK to the server). There is no problem with logical pages. I am copying Hebrew text written using Mellel for OSX: http://homepage.mac.com/redlex/

OK, now this bug is back both to OSX and OS 9.x nightly builds of Mac OS. Very annoying

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

this is ok for me now on mac os 9.2.1 and osx.

This seems to be WORKSFORME on all pages now.