Issues with the Mark in Character set menu on Mac

RESOLVED WORKSFORME

Status

()

P3
major
RESOLVED WORKSFORME
20 years ago
17 years ago

People

(Reporter: teruko, Assigned: nhottanscp)

Tracking

({helpwanted, intl, platform-parity})

Trunk
mozilla1.0.1
PowerPC
Mac System 8.5
helpwanted, intl, platform-parity
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

20 years ago
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.
(Reporter)

Updated

20 years ago
Priority: P3 → P2

Updated

20 years ago
Assignee: trudelle → saari

Comment 1

20 years ago
reassigning to saari for triage

Updated

20 years ago
Status: NEW → ASSIGNED

Updated

20 years ago
Target Milestone: M10

Comment 2

20 years ago
Dup of another bug about checked items

Comment 3

20 years ago
Dup of another bug about checked items

Updated

19 years ago
Whiteboard: half done

Comment 4

19 years ago
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

Updated

19 years ago
Blocks: 12670

Updated

19 years ago
Whiteboard: half done → half done, need to add support for type="checkbox"

Updated

19 years ago
Target Milestone: M10 → M11

Comment 5

19 years ago
type="checkbox" works for MacOS now.

Pushing the XPMenu part of this to M11

Comment 6

19 years ago
*** Bug 14664 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

19 years ago
QA Contact: phillip → teruko
(Reporter)

Comment 7

19 years ago
*** Bug 15131 has been marked as a duplicate of this bug. ***

Updated

19 years ago
Blocks: 15157

Updated

19 years ago
Assignee: saari → shaver
Status: ASSIGNED → NEW

Comment 8

19 years ago
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.

Comment 10

19 years ago
reassigning to cata
Assignee: teruko → cata

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Target Milestone: M11 → M12

Comment 11

19 years ago
Moved to M12, not going to make it for M11...

Updated

19 years ago
Blocks: 18471

Updated

19 years ago
Blocks: 18951

Updated

19 years ago
Target Milestone: M12 → M13

Updated

19 years ago
Blocks: 20761

Comment 12

19 years ago
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.

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 13

19 years ago
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.

Updated

19 years ago
Blocks: 24854
(Reporter)

Comment 14

19 years ago
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
(Reporter)

Updated

19 years ago
Resolution: FIXED → ---

Comment 15

19 years ago
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...
(Reporter)

Updated

19 years ago
Keywords: beta1

Comment 16

19 years ago
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
(Reporter)

Comment 17

19 years ago
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+]

Updated

19 years ago
Whiteboard: [pdt+]

Updated

19 years ago
Whiteboard: [pdt+] → [PDT+]

Updated

19 years ago
Whiteboard: [PDT+] → [PDT+] ETA: 10/Feb

Updated

19 years ago
Depends on: 27433

Updated

19 years ago
Whiteboard: [PDT+] ETA: 10/Feb → [PDT+] ETA: 10/Feb Backend work in, but I depend on #27433

Comment 18

19 years ago
Fixed.
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED
(Reporter)

Comment 19

19 years ago
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 → ---
(Reporter)

Comment 20

19 years ago
This does not work in 2000021608 Mac build.

Comment 21

19 years ago
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

Comment 22

19 years ago
*** Bug 28739 has been marked as a duplicate of this bug. ***

Comment 23

19 years ago
Putting on pdt- radar, will release note for Mac.
Keywords: relnote
Whiteboard: [PDT+] Mac depends on #27947 → [PDT-] FixMac depends on #27947

Comment 24

19 years ago
IQA, Please try this in tomorrow's (2/25) build.  It should be fixed by the
fix for bug 27947.

Comment 25

19 years ago
The bug #11774 depends on was fixed. This should work now. Only needing 
verification.
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED
(Reporter)

Comment 26

19 years ago
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 → ---

Comment 27

19 years ago
Bug 25073 was fixed on 3/7.  Has this bug been retested?

Comment 28

19 years ago
Unfortunately, there's a new regression for radio menus on Mac. We are depending 
on 31104 now.
Depends on: 31104

Comment 29

19 years ago
cata, please clean up REOPEN and mark it ASSIGN if you are working on this bug. 
(or waiting for the depend bug)

Updated

19 years ago
Status: REOPENED → ASSIGNED
Whiteboard: [PDT-] FixMac depends on #27947 → [PDT-] FixMac depends on #31104

Comment 30

19 years ago
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. 

Comment 31

19 years ago
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

Comment 32

19 years ago
This is a bugfix, not feature - moving to M17.
Target Milestone: M16 → M17

Updated

19 years ago
Keywords: beta2

Comment 33

19 years ago
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?

Comment 34

19 years ago
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.
(Reporter)

Comment 35

19 years ago
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.   

Updated

19 years ago
Keywords: nsbeta2

Comment 36

19 years ago
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [PDT-] FixMac depends on #31104 → [nsbeta2+][PDT-] FixMac depends on #31104

Comment 37

19 years ago
The bug we were depending on was fixed, so...
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED
(Reporter)

Comment 38

19 years ago
This still is not working correct in 2000-06-09-08-M17 Mac build.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 39

19 years ago
*** Bug 31708 has been marked as a duplicate of this bug. ***

Comment 40

19 years ago
Updating the bug to reflect the current situation.
Status: REOPENED → ASSIGNED
Keywords: beta1, nsbeta2, relnote → pp
OS: Windows NT → All
Hardware: All → Macintosh
Whiteboard: [nsbeta2+][PDT-] FixMac depends on #31104

Updated

19 years ago
Summary: Need Mark in Character set menu once selected → Issues with the Mark in Character set menu on Mac

Updated

19 years ago
No longer blocks: 18471

Updated

19 years ago
No longer blocks: 18951
(Reporter)

Comment 41

19 years ago
Nominating this for beta2.
Keywords: nsbeta2

Comment 42

19 years ago
Putting on [nsbeta2-] radar. Not critical to beta2. 
Whiteboard: [nsbeta2-]

Updated

19 years ago
Keywords: correctness, nsbeta3
(Assignee)

Comment 43

19 years ago
*** Bug 45632 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 44

19 years ago
This is not generic Mac check mark issue.  This is only Character Coding menu 
problem.

Comment 45

19 years ago
Reassign to myself for now.
Assignee: cata → ftang
Status: ASSIGNED → NEW
Whiteboard: [nsbeta2-] → [nsbeta3+]

Comment 46

19 years ago
Putting on the [nsbeta2-] radar.
Whiteboard: [nsbeta3+] → [nsbeta3+][nsbeta2-]

Comment 47

19 years ago
mark as assign
Status: NEW → ASSIGNED

Comment 48

19 years ago
mark it as assign

Comment 49

18 years ago
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 ?

Comment 50

18 years ago
need some help from someone understand XUL and Mac menu
Keywords: helpwanted
i'm confused, what's the problem?

Updated

18 years ago
OS: All → Mac System 8.5

Comment 52

18 years ago
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
Last Resolved: 19 years ago18 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 53

18 years ago
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 → ---

Comment 54

18 years ago
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

Comment 55

18 years ago

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

Comment 56

18 years ago
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

Comment 57

18 years ago
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
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
(Reporter)

Comment 60

18 years ago
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

Comment 62

18 years ago
try this again, it seems to work fine, at least far as I can tell

(Reporter)

Comment 63

18 years ago
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.

Comment 65

18 years ago
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

Comment 66

18 years ago
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

Comment 67

18 years ago
Targeting Mozilla 1.0
Target Milestone: Future → mozilla1.0

Updated

18 years ago
Keywords: nsbeta1

Updated

18 years ago
Keywords: intl
(Reporter)

Comment 68

18 years ago
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

Comment 70

18 years ago
this is so not dogfood

Comment 71

18 years ago
I think she meant CatFood.

Comment 72

18 years ago
Pls re-eval for M0.9.2.

Comment 73

18 years ago
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?
(Reporter)

Comment 74

18 years ago
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.

 

Comment 75

18 years ago
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'.

Updated

17 years ago
Keywords: nsBranch

Updated

17 years ago
Blocks: 99194

Comment 76

17 years ago
moving off the nsbranch radar.  let me know if this is a mistake.
Keywords: nsbranch

Comment 77

17 years ago
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

Comment 78

17 years ago
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-
(Reporter)

Comment 79

17 years ago
Yuying, please retest this since this is very old bug.

Comment 80

17 years ago
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.

Comment 81

17 years ago
marking as nsbranch-
Keywords: nsbranch-

Updated

17 years ago
No longer blocks: 99194

Comment 82

17 years ago
Cleaning up the Whiteboard.
Whiteboard: [nsbeta3-][nsbeta2-]

Updated

17 years ago
Blocks: 104166

Comment 83

17 years ago
-> pinkerton. Check if this happens on OS X, if not, I'd say future it
Assignee: saari → pinkerton
Status: ASSIGNED → NEW

Updated

17 years ago
Blocks: 107067

Updated

17 years ago
Keywords: nsbranch-

Comment 84

17 years ago
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

Updated

17 years ago
No longer blocks: 107067
over to nhotta who has a patch for i think the very same bug.
Assignee: pinkerton → nhotta
(Assignee)

Comment 86

17 years ago
Yuying, what are the remaining problems? I fixed the menu checkmark bug 98625 on
trunk recently.

Comment 87

17 years ago
It turns out that I can not reproduce this problem on latest build.
(Assignee)

Comment 88

17 years ago
Was that check mark problem? If so, this can be dup of bug 98625.

Comment 89

17 years ago
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?
(Assignee)

Comment 90

17 years ago
That fine. 
BTW, please verify bug 98625

Comment 91

17 years ago
Resolve this as works for me.
Status: NEW → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.