Closed Bug 11774 Opened 25 years ago Closed 22 years ago

Issues with the Mark in Character set menu on Mac

Categories

(Core :: XUL, defect, P3)

PowerPC
Mac System 8.5
defect

Tracking

()

RESOLVED WORKSFORME
mozilla1.0.1

People

(Reporter: teruko, Assigned: nhottanscp)

References

Details

(Keywords: helpwanted, intl, platform-parity)

In the Character set menu, the mark in the menu which character set is selected is missing.

Steps of reproduce
1. Launch Apprunner
2. Go to http://home.netscape.com/ja/
3. Select menu View|Character set->Japanese (Shift_JIS)
4. Select menu View|Character set

   At that time, the Japanese(Shift_JIS) menu should be marked.

Tested 8-12-10 Win32 and MAC, 8-10 Linux build.
Priority: P3 → P2
Assignee: trudelle → saari
reassigning to saari for triage
Status: NEW → ASSIGNED
Target Milestone: M10
Dup of another bug about checked items
Dup of another bug about checked items
Whiteboard: half done
Mac and XPMenus can display check marks now if you set checked="true" on a
menuitem.

However, hyatt and myself have more plans for this, so I'm leaving the bug open
Blocks: 12670
Whiteboard: half done → half done, need to add support for type="checkbox"
Target Milestone: M10 → M11
type="checkbox" works for MacOS now.

Pushing the XPMenu part of this to M11
*** Bug 14664 has been marked as a duplicate of this bug. ***
QA Contact: phillip → teruko
*** Bug 15131 has been marked as a duplicate of this bug. ***
Blocks: 15157
Assignee: saari → shaver
Status: ASSIGNED → NEW
shaver, this is yours. Thanks!
Assignee: shaver → teruko
Whiteboard: half done, need to add support for type="checkbox"
<menuitem type="checkbox"/> works now in XPMenus, so this is up to the owners of
those menus.
reassigning to cata
Assignee: teruko → cata
Status: NEW → ASSIGNED
Target Milestone: M11 → M12
Moved to M12, not going to make it for M11...
Blocks: 18471
Blocks: 18951
Target Milestone: M12 → M13
Blocks: 20761
Checkmark code reviewed by erik and ready for checkin. This adds an API on the
charset menu code. This API will set the the checkmark for an item.

However, this will not be visible until we hook up the event code (bug #24030)
that will call this API.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
So, this is fixed. Again, mark is not visible just yet, because we don't set
it. But that's bug #24030, the code for this bug is all in and tested.
Blocks: 24854
I do not think I can verify this in M13 since the mark is not visible.
I would like to reopen this to keep track and change M14.
Status: RESOLVED → REOPENED
Target Milestone: M13 → M14
Resolution: FIXED → ---
Actually, it is visible. If you use one of the charsets from the "Character Set" 
menu (not "More") a checkmark will appear. Not being connected with the 
events, it is does not have a consistent behaviour. But you can see it...
Keywords: beta1
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
Cata, I see the mark under your character set menu.  However, the mark is not visible in the other character set menu 
and function is not working. This should be fixed in beta1.
Whiteboard: [PDT+]
Whiteboard: [pdt+]
Whiteboard: [pdt+] → [PDT+]
Whiteboard: [PDT+] → [PDT+] ETA: 10/Feb
Depends on: 27433
Whiteboard: [PDT+] ETA: 10/Feb → [PDT+] ETA: 10/Feb Backend work in, but I depend on #27433
Fixed.
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
I verified this in 2000022108 Win32 and Linux build.  However, this does not work in 200022108 and 2000021808 Mac build.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This does not work in 2000021608 Mac build.
I assume the current status (not working on Mac) is dependent upon
       bug 27947 "oncreate"/"ondestroy" are never fired for mac menus
Depends on: 27947
Whiteboard: [PDT+] ETA: 10/Feb Backend work in, but I depend on #27433 → [PDT+] Mac depends on #27947
*** Bug 28739 has been marked as a duplicate of this bug. ***
Putting on pdt- radar, will release note for Mac.
Keywords: relnote
Whiteboard: [PDT+] Mac depends on #27947 → [PDT-] FixMac depends on #27947
IQA, Please try this in tomorrow's (2/25) build.  It should be fixed by the
fix for bug 27947.
The bug #11774 depends on was fixed. This should work now. Only needing 
verification.
Status: REOPENED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → FIXED
I tested this in 2000030108 Win32, MAC, and 2000030113 Linux build.

Win32 and Linux
  After Mozilla.exe is launched, only Auto-Detect off menu is marked under the View|Character Coding Menu.
  Then, I go to www.yahoo.co.jp and select menu View|Character Coding ->Multibyte->Japanese (EUC-JP),
         Japanese (EUC-JP) will go to under Character Coding menu, but it is not marked.
  Even I select Auto-Detect (Japanese) menu, the menu is not marked.

  This might be releted the bug 29661 which is dup to bug 25073.

MAC
  After Mozilla.exe is launched, Auto-Detect off menu and Western (ISO-8859-1) are marked under the View|Character 
  Coding Menu.
  Then, I go to www.yahoo.co.jp and select menu View|Character Coding ->Multibyte->Japanese (EUC-JP),
  Japanese (EUC-JP) will go to under Character Coding menu, but it is marked.  At this time, both Western (ISO-8859-1) and
  Japanese (EUC-JP) menu are marked.  Only Japanese (EUC-JP) menu should be marked. I need to reopen this.
  Auto-Detect menu is marked correctly.


  
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Bug 25073 was fixed on 3/7.  Has this bug been retested?
Unfortunately, there's a new regression for radio menus on Mac. We are depending 
on 31104 now.
Depends on: 31104
cata, please clean up REOPEN and mark it ASSIGN if you are working on this bug. 
(or waiting for the depend bug)
Status: REOPENED → ASSIGNED
Whiteboard: [PDT-] FixMac depends on #27947 → [PDT-] FixMac depends on #31104
This looks horrible and the user has no idea what the setting is.  Here is
an update from teruko:

I tested this in 3-17-12 nb1b Mac build. 
Everytime I select one of View|Character coding, it added to the list, but 
everything is marked. 

For example, 
   1. Launch Navigator 
   2. Look at the menu under View|Character coding 
       Western (ISO-8859-1) menu is marked 
   3. Go to http://babel/automation/websites/altavista 
   4. Select menu View|Character coding->Multibyte->Korean(Euc-KR) 
   5. Check menu View|Character coding 
       There are 2 menu Western (ISO-8859-1) and Korean (EUC-KR) under Character 
coding menu, 
       but both menus are marked. 
In mac, marking check in the Character coding menu is not consistant. 
The bug we depend on (#31104) is marked M18. I'm moving this to M16, in the hope 
that I'll have the time to take a look at that myself. Or maybe Pink will change 
his mind. But don't hold your breath...
Target Milestone: M14 → M16
This is a bugfix, not feature - moving to M17.
Target Milestone: M16 → M17
Keywords: beta2
OK, I need to include this in the Rel notes. It seems that
the major problem is in Mac and Win & Linux have minor
problems. Does this accurately describe the remaining bug?
On Windows, I'm seeing the checkmark is not being updated
under Auto-Detection setting. For example, if the first site
is in Shift_JIS which is reflected in the checkmark, but when
we go visit another site which is EUC-JP but not marked in the
document, Auto-detection can display is but the checkmark is not
refreshed. This is not as bad as Mac described above.
On Mac, the marking check in the Character coding menu is not consistant.
For example, 
   1. Launch Navigator 
   2. Look at the menu under View|Character coding 
       Western (ISO-8859-1) menu is marked 
   3. Go to http://babel/automation/websites/altavista 
   4. Select menu View|Character coding->Multibyte->Korean(Euc-KR) 
   5. Check menu View|Character coding 
       There are 2 menu Western (ISO-8859-1) and Korean (EUC-KR) under Character 
coding menu, 
       but both menus are marked. 
   6. Go to http://www.yahoo.co.jp
   7. Select menu View|Character Coding->Japanese(Euc-JP)
   8. Check again menu View|Character coding 
       There are 2 menu Western (ISO-8859-1), Korean (EUC-KR), and Japanese 
(Euc-JP) under Character coding menu. Western and Korean menus are 
marked, but Japanese (EUC-JP) is not marked.

Tested 2000032800 Mac build.   
Keywords: nsbeta2
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [PDT-] FixMac depends on #31104 → [nsbeta2+][PDT-] FixMac depends on #31104
The bug we were depending on was fixed, so...
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
This still is not working correct in 2000-06-09-08-M17 Mac build.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Bug 31708 has been marked as a duplicate of this bug. ***
Updating the bug to reflect the current situation.
Status: REOPENED → ASSIGNED
Keywords: beta1, nsbeta2, relnotepp
OS: Windows NT → All
Hardware: All → Macintosh
Whiteboard: [nsbeta2+][PDT-] FixMac depends on #31104
Summary: Need Mark in Character set menu once selected → Issues with the Mark in Character set menu on Mac
No longer blocks: 18471
No longer blocks: 18951
Nominating this for beta2.
Keywords: nsbeta2
Putting on [nsbeta2-] radar. Not critical to beta2. 
Whiteboard: [nsbeta2-]
Keywords: correctness, nsbeta3
*** Bug 45632 has been marked as a duplicate of this bug. ***
This is not generic Mac check mark issue.  This is only Character Coding menu 
problem.
Reassign to myself for now.
Assignee: cata → ftang
Status: ASSIGNED → NEW
Whiteboard: [nsbeta2-] → [nsbeta3+]
Putting on the [nsbeta2-] radar.
Whiteboard: [nsbeta3+] → [nsbeta3+][nsbeta2-]
mark as assign
Status: NEW → ASSIGNED
mark it as assign
pinkerton- we need  your help here.
I put some dump code into the JavaScript which will set the "checked"  to "true" 
for those menu item. I also put some printf in the nsMenu.cpp SetCheckMark 
method. Somehow they looks different. Do we play some trick on Mac for those 
menu code ? How can I make sure the nsIDOMDocuemnt the JavaScript setting is the 
same one that the menu code is pulling ?
need some help from someone understand XUL and Mac menu
Keywords: helpwanted
i'm confused, what's the problem?
OS: All → Mac System 8.5
somehow the problem is fixed by someone else. I can no longer reproduce this 
problem. Mark it as work for me now.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → WORKSFORME
I tested this in 2000-09-06-04 Mac build.  This still happens.

Steps of reproduce
1. Create new profile and launch Netscape 6
2. Go to http://www.yahoo.co.jp/
3. Select menu View|Character Coding-> More->East Asian->Japanese(EUC-JP)
4. Select menu View|Character Coding
   The menu Western (ISO-8859-1) has a check mark.  Japanese (EUC-JP) should 
have a check mark.

5. Go to http://www.zdnet.co.jp/
6. Select menu View|Character Coding
   The menu Western (ISO-8859-1) still has a check mark. Japanese (Shift_JIS)
should have a check mark.
I reopen this bug.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I think this is not a generic Mac menu problem. I try Composer and select 
Heading 1 from the toolbar dropdown and it does reflect correctly in the menu.

Currently, we use the following code to check the check mark

121 function UpdateCurrentCharset()
122 {
123     var wnd = document.commandDispatcher.focusedWindow;
124     if (window == wnd) wnd = window._content;
125 
126     var charset = wnd.document.characterSet;
127         dump("Update current charset: " + charset + "\n");
128 
129     var menuitem = document.getElementById('charset.' + charset);
130 
131     if (menuitem) {
132         menuitem.setAttribute('checked', 'true');
133     }
134 }

in 
http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/charsetOve
rlay.js#127
I take my previous comment back. I think this is a generic problem on Mac menu
I can reproduce this problem on Composer- see 51957. 
Could be related to 51685

reassign this to pinkerton
Assignee: ftang → pinkerton
Status: REOPENED → NEW
i think this is now a dupe of 51685, a recent regression.
Depends on: 51685
51685 down, closing this out
Status: NEW → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
I tested this in 2000-09-11-08 Mac build.  This still happens.

Steps of reproduce
1. Create new profile and launch Netscape 6
2. Go to http://www.yahoo.co.jp/
3. Select menu View|Character Coding-> More->East Asian->Japanese(EUC-JP)
4. Select menu View|Character Coding
   The menu Western (ISO-8859-1) has a check mark.  Japanese (EUC-JP) should 
have a check mark.

5. Go to http://www.zdnet.co.jp/
6. Select menu View|Character Coding
   The menu Western (ISO-8859-1) still has a check mark. Japanese (Shift_JIS)
should have a check mark.
7. Go to http://home.netscape.com/ja
8. Select menu View|Character Coding
   The menu Western (ISO-8859-1) still has a check mark. Japanese (Shift_JIS)
should have a check mark.
I reopen this bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
oooh chriiiiiiiiiiis ;)
Assignee: pinkerton → saari
Status: REOPENED → NEW
try this again, it seems to work fine, at least far as I can tell

I tested this in 2000-09-13-12 Mac build.  This is still reproduciable.
from teruko's steps, it works fine up to step six, where Japanese EUC-JP is still 
checked, not Japanese Shift_jis

Step 4 says western is incorrectly checked, I do not find that to be the case. 
Step 4 has the correct option selected.
So the act of going to a new site should magically select a new charset. How
does it do that? Attribute setting or during the construction of the menu?
Status: NEW → ASSIGNED
nsbeta3-/future.  This does not fit the P1/P2 criteria established by PDT, IMO, 
since there is no crash, data loss, functional loss, standards failure, or 
major contractual requirement; and the incorrect behavior is low profile. Feel 
free to escalate to PDT if you think otherwise.
Priority: P2 → P3
Whiteboard: [nsbeta3+][nsbeta2-] → [nsbeta3-][nsbeta2-]
Target Milestone: M17 → Future
Targeting Mozilla 1.0
Target Milestone: Future → mozilla1.0
Keywords: nsbeta1
Keywords: intl
Changed QA contact to ylong@netscape.com.
QA Contact: teruko → ylong
nominating for dogfood (from sdagley's list of bugs that are good candidates for 
our next release) 
Keywords: nsdogfood
Keywords: nsCatFood
Keywords: nsdogfood
this is so not dogfood
I think she meant CatFood.
Pls re-eval for M0.9.2.
Um, because ... ?

There isn't even a statement of substance in here in since Sept. 2000. 
Has i18n QA confirmed that this is still a bug?
This still happens in 2001-05-29-08 Mac Trunk build.

If the page has meta-charset info, the check mark in Character coding menu does 
not indicate the info.

For example,
After you launch the Netscape (default charset is Western (ISO-8859-1), 
if you go to http://home.netscape.com/ja (Shift_JIS is meta charset), Westerm 
(ISO-8859-1) in Character coding has check mark.

then, if you go to http://home.netscape.com/ko (Korean EUC-KR is meta charset),
Westerm (ISO-8859-1) in Character coding menu has still check mark.

However, if you shoose the character coding menu from static menu, the check 
mark will change the menu whatever you choose.

 
I can only refer to my comment above, from September 15 of last year. While I am
sorry to see this defect is still in the product, it does not fit the profile
for bugs we can target for 0.9.2.  Please feel free to either explain how this
is important, or escalate it, or attach a patch for consideration during
'limbo'.
Keywords: nsBranch
Blocks: 99194
moving off the nsbranch radar.  let me know if this is a mistake.
Keywords: nsbranch
can you mark it nsbranch- instead of removing the nomination? at least we can
revisit the nsbranch- for a future release without having to renominate them
I agree with Montse.  For future projects it will be great to have the nsBranch
marking so we can re-evaluate these bugs.  Let's mark with nsbranch-
Yuying, please retest this since this is very old bug.
This one is not reproducible all the time, but it still existing some times at
lest on my Mac9.0.  I think we better to fix it.
So I'd like to keep this open, till we find a good solution for it.
marking as nsbranch-
Keywords: nsbranch-
No longer blocks: 99194
Cleaning up the Whiteboard.
Whiteboard: [nsbeta3-][nsbeta2-]
Blocks: 104166
-> pinkerton. Check if this happens on OS X, if not, I'd say future it
Assignee: saari → pinkerton
Status: ASSIGNED → NEW
Blocks: 107067
Keywords: nsbranch-
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
No longer blocks: 107067
over to nhotta who has a patch for i think the very same bug.
Assignee: pinkerton → nhotta
Yuying, what are the remaining problems? I fixed the menu checkmark bug 98625 on
trunk recently.
It turns out that I can not reproduce this problem on latest build.
Was that check mark problem? If so, this can be dup of bug 98625.
It was check mark problem, but even on recently branch build with Mac OS 9x, I
still can not reproduce it any more.

So maybe we can resolve it as works for me?
That fine. 
BTW, please verify bug 98625
Resolve this as works for me.
Status: NEW → RESOLVED
Closed: 24 years ago22 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.