Closed Bug 79676 Opened 19 years ago Closed 12 years ago

land bidi pref ui xul and js files


(SeaMonkey :: Preferences, enhancement)

Not set


(Not tracked)



(Reporter: ftang, Unassigned)


(Depends on 1 open bug, Blocks 1 open bug)


(Keywords: helpwanted, Whiteboard: patch disapproved by sr. need to work on new js code.)


(6 files)

in the IBMBIDI work we creaet a new pref window for bidi control. We need to 
land the UI. This bug is for bidi-prefs.js and bidi-prefs.xul only. it depend on 
79675 for the dtd. We probably need to land 79675 first since we need to freeze 
L10N translation first.
Depends on: 79675
here is the xul and js change, this have to be land 
1. after we land 79675
2. after we turn on IBMBIDI as default
No longer depends on: 79675
ben- can you also code review this one ?
The author is
Depends on: 79675
Blocks: 79684
Whiteboard: need code review
Whiteboard: need code review → need code review2001-05-09 06:29
*** Bug 79679 has been marked as a duplicate of this bug. ***
add better patch which merge with 79679 and have MANIFEST and other build stuff.
Attached patch newest patchSplinter Review
ben- can you review this- 

the discussion of the functionality of this patch could be found at
Whiteboard: need code review2001-05-09 06:29 → new patch need review 2001-05-15 17:02
Target Milestone: --- → mozilla0.9.1
this is the wrong approach to solving this problem. You should be using pref
observers, NOT registering ok handlers on the pref window - not to mention that
your change only affects the most recent window, and does not affect any other

Please look at nsIPrefBranch.addObserver() - there are examples in the tree,
such as in navigator.js, look for the "nsButtonPrefListener" - basically every
navigator window (and perhaps mail window too? maybe you want to integrate this
into the markupDocumentViewer object instead?) should act as an observer on the
pref that you'll be changing.. when the pref changes, you should examine the new
value, and set the value of viewer.bidiTextDirection.
reassign back to simon to work on. 
jbetak- can you help?
simon- please work with together with this issue. jbetak 
work for me and know pref stuff pretty well.
when you guys get the new patch, reassign this bug to jbetak for check in. 
I am not sure we still have enough time for moz0.9.1- it will be freeze at 5/22. 
we probably can still make it if we get the newest patch by Friday morning 5/18
Assignee: ftang → simon
Whiteboard: new patch need review 2001-05-15 17:02 → patch disapproved by sr. need to work on new js code.
so... here are the issues
1. the UI design of the BIDI pref
   I believe everyone agree with the design since it have been on the bidi build 
for a while- please open new bug if there are problem with the design
2. XUL structure
   I believe there are no problem with that - alecf does not mention any issue 
about the xul
3. JS file
   alecf said we need to 
   a. use pref observe instead of ok handler
   b. it should affect all the window but not just the most recent window.
alecf- can we land the patch without prefwindow/resources/content/preftree.xul 
now and keep working on ? This will make sure the current ui design is in the 
tree and will be easier to work between people. We won't bring up the ui if we 
don't land the preftree.xul changes. 
Here are some problems I see with the UI at a glance:

* Is this really Navigator-specific?  Why is it under Navigator?
* Everything in the Preferences dialog is an option.  We don't need to append 
"Options" to the category name.
* I suspect that many users aren't going to know what "Bidi" means.  But it 
looks as if not everything in this panel has to do with bidirectional text 
* The panel doesn't fit (due in part to the overabundance of groupboxes and 
* Inconsistency in widget placement (Logical and Visual are sometimes the first 
two, sometimes the last two.)
* Inconsistency in capitalization ("Text Mode in Controls", "Text Mode in 

Feel free to check this UI into the tree as-is to facilitate work on it, but it 
cannot be turned on until these and other issues are addressed.  I'll file a new 
bug to cover them.
Is there a UI designer working on a design for this? As blake pointed out, there
are many inconsistencies and the dialog is very complex. I'd like to see a new
patch and a new screenshot with a more consistent UI.

I also agree that:
1) "Bidirectional Text" should be used instead of "BiDi" wherever there is room.
2) This really seems to belong in Appearance, not Navigator, since it affects
mail and editor as well.

And so
1) no, please don't land the UI as-is
2) do NOT land any JS that makes use of registerOKCallbackFunc()
TM to 0.9.2 per PDT triage (it's OK to check it in by Friday or after 0.9.1
branch is made).
Target Milestone: mozilla0.9.1 → mozilla0.9.2

just trying to clarify - would simon target navigator.js for inclusion of his 
pref observers? I agree that markupDocumentViewer seems like an even more 
natural choice, which would imply nsDocumentViewer.cpp, right?
Sorry, I don't begin to understand alecf's recommendation concerning pref 
observers. I am especially confused about what should be in .js and what should 
be in .cpp

jbetak, it looks as if I'm going to need *lots* of help on this. Thanks in 
ok, the issue is that your fix causes a change only to the most recent window,
and only when changed from the preference UI. Why is this bad?
1) Preferences are a global option - if you change a preference, it should
affect the entire product. If what you are changing is per-window, then it's not
a preference.
2) There are multiple ways to change preferences, beyond just the Preference UI
- you should NEVER depend on the ok button callback to update preferences.
Instead, you should be registering with the backend preference code to be
notified whenever a particular pref changes.

So, in order to solve this, you need to add an object that acts as an observer
to preferences changing. Look at nsIPrefBranchInternal.addObserver(). By using
this method, you gaurantee that no matter how a preference is changed (via the
UI, via some backend method, etc) your object will be notified.

Your object(s) can be written in JS or C++, your choice - since the object that
is affected seems to be the markupDocumentViewer, I personally would simply
reuse that object by making it implement the nsIObserver interface. That way,
every instance of that object is an observer, and thus every window will be
affected when you make this change.

I've been looking for some examples for the things alecf pointed out and my 
current belief is that the pref observer should be added to 
nsDocumentViewer.cpp. Luckily, there is some code we could use as a reference 
in nsCacheService.cpp. Here are links to the points of particular interest:

Seems like there are two preference values of interest 
(browser.cache.disk.enable, browser.cache.enable), but they are not really 
exposed to the UI in the release builds. 

I'm working on some urgent UI changes for language/content packs, but I might 
have some free cycles next week to help with the implementation or any other 
changes necessary.
the one thing I want to add about the pref observer stuff which just bit me
elsewhere, is that prefs holds onto a strong reference to your object, so make
sure that you don't create a cycle by making sure you unregister yourself as an
observer someone OTHER than the destructor of that object...
I have the following question
1. who should we work with for the UI design/redesign ? what is the process? Who 
can make the decision?
2. Where should we put under pref tree? blake said we should not put under 
navigator, should we put under "Apperance" ?
3. what should the title of the pref be ? should it be "Bi-Directional Text" ?
4. Should all the setting in the pref? 
5. What kind of widget should we use? currently it use radio, should we use 
PopUp instead to save some space?
6. What should be the langauge used in the pref. The sentance/langauge in the 
pref currently is hard to understand. 
7. How freqent the user may change the pref? Switch depend on the page ? Depend 
on the OS ? We should have answer for each setting.

Here is the documentation I can find:

 82   /**
 83    * Options for Bidi presentation.
 84    *
 85    * Use these attributes to access the individual Bidi options.
 86    */
 88   /**
 89    * bidiTextDirection: the default direction for the layout of 
bidirectional text.
 90    *                    1 - left to right
 91    *                    2 - right to left
 92    */
 93   attribute octet bidiTextDirection;
 95   /**
 96    * bidiTextType: the ordering of bidirectional text. This may be either 
 97    * or "visual". Logical text will be reordered for presentation using the 
 98    * Bidi Algorithm. Visual text will be displayed without reordering. 
 99    *               1 - the default order for the charset
100    *               2 - logical order
101    *               3 - visual order
102    */
103   attribute octet bidiTextType;
105   /**
106    * bidiControlsTextMode: the order of bidirectional text in form controls.
107    *                       1 - logical
108    *                       2 - visual
109    *                       3 - like the containing document
110    */
111   attribute octet bidiControlsTextMode;
113   /**
114    * bidiClipboardTextMode: the order in which text is transferred to the 
115    *                        1 - logical
116    *                        2 - visual
117    *                        3 - as source (unchanged)
118    */
119   attribute octet bidiClipboardTextMode;
121   /**
122    * bidiNumeral: the type of numerals to display. 
123    *              1 - depending on context, default is Arabic numerals
124    *              2 - depending on context, default is Hindi numerals
125    *              3 - Arabic numerals
126    *              4 - Hindi numerals
127    */
128   attribute octet bidiNumeral;
130   /**
131    * bidiSupport: whether to use platform bidi support or Mozilla's bidi 
132    *              1 - Use Mozilla's bidi support
133    *              2 - Use the platform bidi support
134    *              3 - Disable bidi support
135    */
136   attribute octet bidiSupport;
138   /**
139    * bidiCharacterSet: whether to force the user's character set
140    *                   1 - use the document character set
141    *                   2 - use the character set chosen by the user
142    */
143   attribute octet bidiCharacterSet;  
145   /**
146    * Use this attribute to access all the Bidi options in one operation
147    */
148   attribute PRUint32 bidiOptions;

Based on the documentation, I believe we need the following in the pref
1. Default Direction
2. Numeral Shape
3. Text Type
4. Text Mode in Control
5. Text Mode in Clipboard

We should NOT include "Character Set" neither BidiSupport (which currently not) 
in the pref. the "Character Set" one should be covered by our Forced character 
scheme for all characters set- this is not bidi-specific.

In term of numeral shape, I wonder what does that mean to other locale. Will 
people want a Thai numeral shape in the future? What should we deal with them?

I will propose that we use popup for all these setting. OF course, once we find 
THE UI designer  I will let him/her decide that.

see my comment about numerica shaping in 79682. We may want to simply listen to 
OS control panel instead.
Attach a hacky prototype by using HTML. We should really use XUL to implement 
it. This is just a quick and dirty way to demostrate the look and feel. Notice 
that if you use Netscape6 to view it, the Numeric shap will show you Hindi 
(which is the non ASCII digits) in the options. 
As I mention before, we may or may not want to have preference for Numeric 
Shape. We may want to listen to OS control panel instead. 

If we want to add Add Numeric Shape, then we need to consider 
1. how about Persian?
2. how about other unicode digits- such as Thai, Devanagari, etc

How fine is the OS control panel setting for Numeric Shape? Do they have the 
same 4 options on Mac and Windows? how about Linux/Solaris?
There's a problem with showing examples (1,2, 3, etc.) in the pop-up for Numeric
shaping: the current pref will be applied to the examples, so they may end up
looking both the same. Is using image files an option?
> 1. who should we work with for the UI design/redesign ?

Blake Ross, Ben Goodger, myself, and the others subscribed to n.p.m.ui and 

>                                                         what is the process?

Post a message to n.p.m.ui and n.p.m.i18n explaining exactly what each of these 
options do, why it is that these options are necessary at all in Mozilla when 
most of them are not present in Internet Explorer, and how these options 
interact with OS settings for the same thing. Then respond to questions and 
suggested designs from the UI people, until a final design is reached. Provided 
messages are responded to promptly, this process should take less than a week.

> Who can make the decision?

Blake Ross (owner of XP Apps: GUI), Ben Goodger (owner of Navigator UI), and 
myself (owner of UI Design).

> 2. Where should we put under pref tree?

Judging by my (admittedly incomplete) understanding of what these options do, 
and the discussion in this bug, the answer is probably `nowhere'. But that can 
be worked out in the newsgroup discussion.
>>who can make the decision?

>Blake Ross (owner of XP Apps: GUI), Ben Goodger (owner of Navigator UI), and 
>myself (owner of UI Design)

I don't think that the aforementioned individuals 'can make the decision'. 
While mpt is the owner of "design feedback", and Blake and Ben or very valuable 
contributors to Browser and overall front-end pieces of Mozilla, they don't 
represent the decsion making process alone.
As for commercial Netscape builds the Netscape UI group is the design owner, 
represented here by Jennifer Glick for Messenger, myself for Navigator and the 
overall UI framework and a number of other folks in our group. Keep in mind 
that we are the original creators of the Mozilla UI and participate actively in 
its design process.
It also my opinion that when it comes to international and localization issues 
there are individuals and companies participating in Mozilla (albeit a bit more 
quietly) with signicantly more expertise then the aformentioned folks.

None of us want to be sole 'decision maker' of the UI design and implementation 
process, for reasons of knowledge, time, etc. Where UI is necessary to 
accomplish a feature useful to a subset of users, it is my role (as appointed) 
to /arbitrate/ the design and implementation of this UI such that a) the 
majority is not affected in a negative way and b) the needs of the subset are 

Expertise in the field of knowledge of international customers is fantastic, 
however, one must also temper that knowledge with knowledge of the core 
audience. I've not yet taken the opportunity to familiarize myself with the 
specifics of this bug, so everything I have said thus far are generalities. 
Target Milestone: mozilla0.9.2 → mozilla0.9.3
QA Contact: sairuh → teruko
Andreas, please reassign QA contact to the proper person.
Switching qa contact to and cc to
QA Contact: teruko → giladehven
I think it might be better to have mahar do the
QA for this particular bug because she is most familiar
with the UI options at this point.
QA Contact: giladehven → mahar
mkaply- please help to drive this one.
Assignee: simon → mkaply
This isn't going to happen for 0.9.3. Moving out.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Michael - Is this gonna happen for 0.9.4? If not, please move it out to 0.9.6 or
Moving out. adding helpwanted keyword
Keywords: helpwanted
Target Milestone: mozilla0.9.4 → mozilla0.9.6
Sorry all. Moving this out to 0.9.8 for now.
Target Milestone: mozilla0.9.6 → mozilla0.9.8
Keywords: nsbeta1
Blocks: 115712
answer to comment #24:

about Thai number.
YES, we need it :)
Thai number/digit is widely use in all Thai government agencies/army/royal.
The target milesotone says above 0.9.8
We don't have this for 0.9.9 yet.
I know the hebrew l10n people want this bug fixed...
so- what is going on?
I don't think this is going to make it for 1.0.

We still need to get a consensus on where to put the Bidi UI, especially with 
the new menus.
Target Milestone: mozilla0.9.8 → mozilla1.0.1
Blocks: 80130 is no longer in Arabic bugs, so I have removed her from the CC 
list and added myself instead This comment is to inform you 
of this new status. Thank you.
Kindly be informed that Ahmad A. Abu-Taha ( from IBM Egypt is 
replacing Maha Abou El-Rous ( in monitoring and receiving 
notifications of Mozilla bugs regarding Arabic.
adt: nsbeta1-
Keywords: nsbeta1nsbeta1-
Target Milestone: mozilla1.0.1 → Future
Assignee: mkaply → daniel
Target Milestone: Future → ---
Michael Kaply wrote:

> We still need to get a consensus on where to put the Bidi UI, especially with 
> the new menus.

More than a year has gone by since this last comment. The discussion has pretty
much stalled, so I really can't see anything that'll get us this much elusive

How about adding the BiDi UI as a (popup) settings window? Instead of dedicating
a whole panel, add a Bidirectional Settings button under the Navigator/Languages
panel. We already have the pref for Default Character Coding there, so another
button probably won't cause much confusion or clutter.

BTW,, is there any reason why this bug is assigned to Daniel
Glazman? to the best of my knowledge, he hasn't been involved in it, nor is he
the owner of Browser/Preferences. Could this be an error?

Yeah, I should not be the assignee here. Feel free to reassign.
Neil should weigh in, as XP Apps owner (jag too, cc'ing him).

Assignee: daniel →
Severity: normal → enhancement
Depends on: 251820
As a BiDi user, (except of the numeral shapes option, maybe), I don't see
anything that we need from the attached screenshot, except of (and even this..).
trim "except of (and even this..)." from the end :-)
Product: Browser → Seamonkey
Keywords: qawanted
No comment and hardly any activity in more than 3 years. In the meantime, the prefs UI is being moved to a new backend which didn't exist in Sm 1.x or Mozilla.

Resetting A+QA on the assumption that they aren't current anymore. (Neil, if you still want this, go ahead and re-accept it of course.)
Assignee: neil → nobody
QA Contact: mahar → prefs
Is there any value in this bug still or can we just WONTFIX it?
Blocks: 436934
No longer blocks: prefpane_migration
I think the bidi prefs are fine as hidden prefs in about:config. If we decide we need UI for any of them we can open new bugs.
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.