Closed Bug 82849 Opened 19 years ago Closed 17 years ago

Input widgets on visual pages follow the visual logics

Categories

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

defect
Not set

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: ilya.konstantinov+future, Assigned: mkaply)

References

Details

Attachments

(1 file)

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. 
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?
QA Contact: momoi → mahar
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
Depends on: bidiui
*** 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. 
QA Contact: mahar → zach
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.

Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
I still have to enter Hebrew backwards at
http://www8.huji.ac.il/shnaton/new/search_frameset.html
when using build 2001110821 on Linux
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Blocks: 115711
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
OS: Linux → All
Hardware: PC → All
*** 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.
Status: REOPENED → RESOLVED
Closed: 18 years ago17 years ago
Resolution: --- → WORKSFORME
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: zach → layout.fonts-and-text
You need to log in before you can comment on or make changes to this bug.