Closed Bug 98395 Opened 20 years ago Closed 6 years ago
Need the separate character coding menu in the different frame
7.89 KB, patch
|Details | Diff | Splinter Review|
Right now, we can change character coding menu from View menu only. If the different frame is the different character coding, we cannot change character coding menu for each frame. Steps of reproduce 1. Go to above URL Both frame does not have meta charset info. Left frame page is written as Euc-JP and right frame page is written as Shift_JIS. 2. Select menu View | Character coding->More->East Asian->Japanese (EUC-JP) Only Japanese characters in the left frame page are displayed correctly. It is nice to handle charset in the different frames. Tested 9-05 trunk build.
assigning to ftang for feature implementation.
Assignee: yokoyama → ftang
reassign this to shanjian shanjian, please consider this as m96-m97 feature. we could use the following way to solve this issue 1. display focus frame and let the charset menu frame sensitive. Similar to what we did for print frame in 4.x 2. use contextual menu.
Assignee: ftang → shanjian
Status: NEW → ASSIGNED
Nominating this as nsbeta1.
I have a partial fix on my tree. I have been told that naoki has a working patch. Give it to naoki.
Assignee: shanjian → nhotta
Status: ASSIGNED → NEW
Shanjian, what kind of changes have you done? All we have now is the .js & .xul to hook up to the context menu, no frame support. If you work on the backend change to enabling frame base charset change, please continue working on that. You can reassign back to me if that's not the case.
Assignee: nhotta → shanjian
nsbeta1- because no customer ask for it and it is a *new* feature please talk to roy and hansoo about this.
There are several bugs related to frames and charset encodings and they have been morphing into things which are not always the same as the current Summary. Has this bug morphed into the need for a "backend change to enabling frame base charset change"? If so, there are customers who want to be able to change charset encoding for a given frame. Comments: Bug 26353 http://bugzilla.mozilla.org/show_bug.cgi?id=26353#c28 ...I believe, make a lot of Mozilla users (who need to view non-US-ASCII pages very often among other things) a lot happier :-) or prevent them from turning to MS IE (I have to resort to MS IE frequently because I can't change the encoding, print the page, take the URL, etc in a chromless window) Therefore, I thought it might not be so bad to spur a little more activities here by writing this comment. There are several comments with examples of cases where this is needed in bug 63054: http://bugzilla.mozilla.org/show_bug.cgi?id=63054#c18 http://bugzilla.mozilla.org/show_bug.cgi?id=63054#c19 http://bugzilla.mozilla.org/show_bug.cgi?id=63054#c39 http://bugzilla.mozilla.org/show_bug.cgi?id=63054#c41 In bug 70830, http://bugzilla.mozilla.org/show_bug.cgi?id=70830#c83 I don't agree with mpt in comment #36 saying that "Since the probability of different frames in the same frameset having different encodings (and not only that, but different encodings which cannot even be handled by the same auto-detection module) is surely very low, ..." No, no, the probability isn't very low, but rather getting higher as more and more web-based email sites are available. Most of these web-based email sites (like yahoo.com) use English, thus Latin-1. But users can very well be non-English. In such sites, emails are mostly shown in a frame (except Hotmail, eg). So, it's very likely to have different encodings in different frames. Maybe you would think this only concerns non-Latin-1 users. No, no, wrong again. Think of what happens if someone sends you a message in Unicode!
push to 1.01
Target Milestone: mozilla1.0 → mozilla1.0.1
*** Bug 155509 has been marked as a duplicate of this bug. ***
*** Bug 155858 has been marked as a duplicate of this bug. ***
nsbeta1+ for m1.2final release.
shanjian: please add context charset menu too when browsing non-frame homepages, then you can fix many other bugs like 70830...
Simford, I updated your patch to include charset detector and customize charset menu item. The handler is also changed to the one used by browser menu.
Blaker, could you review the code?
shanjian: I have tried your new patch. It works well but still has a little mess: the menu state can not be synchronized between context menu and View menu. i.e. when you choose a Charset (say A) in context menu, the homepage reloads, the context menu shows that A is current charset, but View/Character Encoding still shows the old one (say B). They are async. However, when you choose the charset encoding from the View/Character Encoding, the context menu will synchronize with it! very strange, huh.
After many tries, I find that it depends on the sequence you use Charset Encoding menu. the 1st test: 1. After lanch Mozilla, 2. open a homepage, 3. change charset encoding with context menu, 4. change charset encoding with View/Character Encoding then context menu state can be sync with View/Character Encoding menu, but viceversa, no. 2nd test: 1, 2, 4, 3 then View menu can be sync with context menu, but no viceversa. Maybe we should use different menu objects instead of pointing to the same one.
Thanks for trying it out. I will look into this.
both the charset menu in browser and charset menu in context, they are generated by the same menu id. So whoever is created first, it will be referenced by "getElementId()". I could not find a solution to this problem yet. An alternative solution is to disable the context charset menu when main menu is available.
The context menu for non-frame part is moved to bug 70830. This bug will soly handle frame charset issue.
cc ben and mpt. Please speakup if you have disagreement again this ui change.
err. there has to be a better way to do this. suppose i end up with a dom something like this: <frameset id=a> <frame id=b> <frameset id=c> <frame id=d> <frame id=e> <frame id=f> <iframe id=g> </frame> </frameset> </frameset> would it be reasonable for me to want to change the character coding of frames D, E and F together? If there was a way to select C and then select a character coding (using the menubar) then I could do that. If I wanted to change the character coding for all of the frames, then if i could select A, then I could use the menubar to select a character coding. This requires three things: 1. being able to select any frameset/frame/iframe. 2. being able to show the menubar (macos has no problem, we can rely on <alt> to show it, or a context menuitem to show it) 3. selecting a character coding from the menubar should affect the selected frame(set) and all children. AaronL: how unreasonable is 1? DanM: i know you're already sick of this and it's new bugs to you, but how unreasonable is 2?
> would it be reasonable for me to want to change the > character coding of frames D, E and F together? It is my understanding that any encoding change should propagate to all the children nodes but not to a parent node. That is how I have understood the spec we have out on Mozilla.org for the past 3 years or so. So what you want would have to occur per spec.
Comment on attachment 100912 [details] [diff] [review] latest patch that only address frame charset encoding. the same charset update problem seems exist in frame context menu as well, need more investigation.
Attachment #100912 - Flags: needs-work+
is that possible you can make a screen shot about the work? I won't mind (neither support) if we do not include those "more charset" submenus if people really feel bad about those ...
ftang, I found a charset update problem which I could not find a solution yet. Before that is solved, I can't move on.
i18n triage team: need info on user base affected.
*** Bug 195341 has been marked as a duplicate of this bug. ***
shanjian is no longer working on mozilla for 2 years and these bugs are still here. Mark them won't fix. If you want to reopen it, find a good owner first.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Mass Re-assinging Frank Tangs old bugs that he closed won't fix and had to be re-open. Spam is his fault not my own
Assignee: shanjian → nobody
Status: REOPENED → NEW
Filter on "Nobody_NScomTLD_20080620"
Assignee: nobody → smontagu
QA Contact: teruko → i18n
Telemetry shows that this feature is used extremely rarely. It is not worthwhile polish this further.
Status: NEW → RESOLVED
Closed: 17 years ago → 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.