Closed Bug 70830 Opened 24 years ago Closed 9 years ago

Can't change page encoding in the windows without menu & toolbar

Categories

(Core :: Internationalization, defect, P4)

Product:
Core
Component:
Internationalization
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: anoripi, Assigned: nhottanscp)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: intl)

Attachments

(13 files, 1 obsolete file)

Diff to reproduce the menu insertin problem, added a context menu and disabled the original charset menu.
1.44 KB, patch
Details | Diff | Splinter Review
Patch, adding a context menu for charset.
5.80 KB, patch
Details | Diff | Splinter Review
Updated patch, the last patch contains debug junk and it doesn't work (sorry).
5.89 KB, patch
Details | Diff | Splinter Review
proposed placement of the "Character coding" menu item in the context menu
15.19 KB, image/jpeg
Details
IE context menu - intended for illustration purposes only
64.13 KB, image/jpeg
Details
Updated patch - reflects the proposed context menu placement for "Character Coding"
6.89 KB, patch
Details | Diff | Splinter Review
better screenshot for the proposed placement of the "Character coding"
54.27 KB, image/jpeg
Details
thanks for looking at this Naoki - here is an updated patch
6.67 KB, patch
Details | Diff | Splinter Review
and an updated screenshot
54.40 KB, image/jpeg
Details
A more revealing picture of how bad MSIE's UI design is
43.99 KB, image/png
Details
Another - and hopefully more usable - proposal (JPG)
30.84 KB, image/jpeg
Details
updated patch - nhotta could you please try it a prehaps give it r=?
2.63 KB, patch
nhottanscp
: review+
Details | Diff | Splinter Review
Removed handlers from charsetOverlay.xul.
2.64 KB, patch
alecf
: superreview+
Details | Diff | Splinter Review
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.8) Gecko/20010215 BuildID: 2001021508 Some JavaScript windows doesn't have menus & toolbars, so if the page encoding goes wrong, i don't have any way to change it. Please insert a menu item to force encoding into the menu when i click the right mouse button on page (like IE...) Reproducible: Always Steps to Reproduce: visit some asian sites which doesn't supply any meta tags about encoding. and some javascripts will make a window without menu... Actual Results: Can't force page encoding, so i can't see asian pages.
ccing mpt for UI thoughts
Changing bug status to New and adding keyword intl and nsbeta1.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: intl, nsbeta1
Status: NEW → ASSIGNED
I can add charset context menu by changing charsetOverlay.xul. <popupset id="contentAreaContextSet"> <popup id="contentAreaContextMenu"> <menu id = "charsetMenu" /> <menuseparator /> </popup> </popupset> I found some problem and I am investigating them. * id "charsetMenu" is already used for the main charset menu, so I need to have a different id to avoid the conflict. * Charset mene is always added at the top of the context menu. If we want to put it somewhere else, I need to find a way to specify the position. * There is a problem of inserting a new charset item into the cache area for context menu. I have to use different index values when I insert to the main charset menu and context charset menu. I posted a question to RDF newsgroup.
Here is more detail information about the menu insertion problem. The menu uses RDF datasource and a menu item is dynamically inserted when the user selects a new item from the "More" submenu. http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/charsetOve rlay.xul#224 The problem I see is when I use the same "charsetMenu" for context menu, the item is inserted at a wrong position. For example, if I am inserting an item between "ISO-8859-1" and "UTF-8", the current code inserts using an index value 3. That works fine for the existing non context menu. In fact, this is very strang. I don't know why it can insert after "ISO-8859-1" with an index value 3. Auto-Detect More Custom... ------------ ISO-8859-1 UTF-8 For context menu, if inserted with index value 3 then it is inserted between "Custom..." and a separator. When I use the index value 5, it works fine. The insertion is done by calling nsIRDFContainer::InsertElementAt. http://lxr.mozilla.org/seamonkey/source/intl/uconv/src/nsCharsetMenu.cpp#1091 When I dump the elements in the container at insertion, I found only items after the separator are in the container. I did not see top three items ("Auto-Detect", "More", "Custom...") in the container. I will attach a patch to reproduce the problem.
Reassing to waterson for the menu insersion problem.
Assignee: nhotta → waterson
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
Let me add a context menu for charset now. We know about the menu insertion problem. But I want to add this feature in mozilla 0.9 and let people use it so they may find other problems. Also it is needed for localization. I will attach a diff.
Bill Law reviewed the patch and found other problems. * Choosing "Customize..." left the initial context menu on the screen (obscuring the Customize... dialog). * Selecting the menu item generates two JS errors like "JavaScript error: line 0: contextMenu has no properties". * Charset menu is at the top, position="N" attribute does not work.
Depends on: 73721
Depends on: 73804
QA Contact: andreasb → ylong
nhotta, I applied the patch, but am not exactly sure what I should be looking for? I see Character Coding -> Auto Detect -> More -> Customize... --- etc. What's the expected behavior?
The problem can be seen when you select a charset from "More". If you select a charset which is not already shown in the main charset menu (i.e. under the separator), then the selected one will be inserted to the main charset menu. The problem is the insert position. Let me explain by using an example. 1) Suppose you have charset menu items as below. Auto-Detect More Custom... ------------ ISO-8859-1 2) Use context menu, select "More"->"West European"->"Western (ISO-8859-15)". 3) Expected result is, Auto-Detect More Custom... ------------ ISO-8859-1 ISO-8859-15 4) But actual result by context menu is, Auto-Detect More Custom... ISO-8859-15 ------------ ISO-8859-1 * If you look at the Non-context charset menu, the item "ISO-8859-15" is inserted in the correct position. * The other thing I noticed is that the checkmark problem (bug 73881) does not happen in the context menu.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
changing to nsbeta1-. this one does not meet beta stopper guidelines.
Keywords: nsbeta1 → nsbeta1-
Assinging P4, since this has been marked as minor by QA.
Priority: -- → P4
Target Milestone: mozilla0.9.2 → mozilla1.0
May I suggest this bug is not that "minor"? Many web programmers forget to set the charset meta tag and casue Mozilla display international character wrongly. Having charset switching menu in context menu is quite useful and important. I need to switch to IE which has this feature when I browse certain websites.
The menu item insertion point problem I mentioned before (2001-05-03 10:28) is gone. I cannot see it when I apply the last patch to the trunk. Reassign to jbetak. Two remaining problem. * the JS error - bug 73804. * position of the menu - charset menu appears at top in the context menu
Assignee: waterson → jbetak
Status: ASSIGNED → NEW
accepting for 0.9.3 - unless there was a compelling reason for the previous 1.0 target milestone.
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla0.9.3
Juraj, please talk to German about position of charset menu in the context menu.
"Auto Detect" and "Customize..." are global setting. I am not sure about "Auto Detect" because it might be needed in order to view a specific page. But I think "Customize..." is not needed as an context menu item.
r=nhotta
cc'ing and separately emailing ben and blake for sr. If we don't hear back from an UI reviewer and can receive an sr, this will go in by midnight.
Whiteboard: have fix, need sr
Sorry, but adding submenus to a context menu -- especially nested ones -- is really not a good idea. Submenus are hard enough to use as it is; when placed in context menus, they become markedly worse, since the placement of the submenu is not reliable because it depends on how close the cursor is to the right and/or bottom edges of the screen. Here's the relevant Windows UI guideline: Keep the length and depth (use of submenus) of a shortcut menu as small as possible. Limit the items you include on the menu to common, frequent actions. -- <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/ html/ch08b.asp> And the relevant Mac UI guideline: Keep the list of items in a contextual menu short, clear, and simple. Use sub-menus reluctantly and keep them to one level. -- <http://developer.apple.com/techpubs/mac/HIGOS8Guide/thig-56.html> The submenus introduced in this patch are not one, not two, but three levels deep, which is pretty much unacceptable. A much better way of fixing the problem in this bug would be to fix bug 26353, by adding a `Show Menu Bar' item to the bottom of every context menu for a window which does not have a menu bar. I imagine that bug would be relatively easy to fix. That way you wouldn't use multiply nested context menus; and not only would you be able to change the encoding, but you'd also become able to do other things which you currently can't do to a page in a chromeless window: editing it in Composer, printing it, sending it by e-mail, changing its style sheet, etc. See attachment 41632 [details] for the latest draft spec for context menus in Navigator and Messenger.
I agree with mpt here. Encoding is just one thing a user may wish to change about a chromeless window, and I believe the best way to solve this problem is to allow the user to re-enable UI taken from them by the author. If the author has not correctly configured the encoding for their document, it is not their perogative to remove UI from users so that they can correct this. Fixing the bug mpt references would fix this bug and potentially a bunch of others, filed or not. Brief Directions to fixing 26353: add a "Show Menu Bar" menu item to the context menu XUL. Set hidden="true" on it. when displaying a context menu: - obtain the <window> node of navigator.xul - obtain the |chromehidden| attribute - check for the presence of the string "menubar" within that attribute value. If so, remove the hidden attribute on the menu item. the handler for "Show Menu Bar" is as follows: - obtain the |chromehidden| attribute on the <window> element. - use string functions to remove the "menubar" segment. - set |chromehidden| again with the modified string. This will cause the menubar to appear. Notes: - this solution won't affect other context menu clients as AFAIK only browser uses the chromehidden attribute. As long as the code checks return values etc it should not harm mailnews or the sidebar. I'd prefer to see a patch that implements the solution outlined above or something similar to it.
I've added a patch to bug 26353 implementing the solution I outlined in my previous comment. I suggest we use that instead of the one here.
I support to add the character set menu in context menu .. maybe list all charset support in the first level or remove the "Auto Detect", "More", "Customize..."
missed the 0.9.3 train - pushing out to 0.9.4. Cc'ing ftang. Frank: both ben and mpt agree that Character Coding doesn't belong to the context menu. Would you like to invalidate this bug or mark it as dup of bug 26353?
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Context menu to be also used controlling charset of a frame. Ben, would that be possible by bug 26353?
Please have a look at attachment 43242 [details], if you already haven't done so. IE might be using a similar approach for a reason, although I'm not defending their particular UI design.
As you can see from the attachment, submenus for context menus get out of hand pretty quickly. In Mozilla it would be even worse than MSIE, partly because of bugs like bug 33188, but mostly because our encoding submenu is even deeper than theirs is. Changing the encoding for an individual frame is bug 63054. 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, then I think it would be acceptable to handle that with two extra radio buttons in the dialog which I proposed for bug 10999: | | Apply these choices to: (*) whole document ( ) selected frame Indeed, an `Encoding...' item in the context menus for both pages and frames would be acceptable if it opened such a dialog, rather than opening a maze of submenus.
URL: http://www.orange.co.il/orange_fun/
Whiteboard: have fix, need sr → have fix, need sr | Anyone got a better testcase?
clearing whitboard status. mpt - thanks for your time and the review. The popup suggestion sounds quite sensible to me and I'll come up with some prototype soon. i18n folks: could we live without a deeply nested charset context menu? The current main menu charset implementation suffers from the same limitations mpt pointed out. Should we attempt to keep both menus sufficiently similar - for the sake of consistency and better recognizability or would we be willing to change both?
Whiteboard: have fix, need sr | Anyone got a better testcase?
As others have already written, this bug is critical for non-English speaking users and has to be fixed (either thru context-menu or by fixing bug 26353). A lot of times I have to launch MS IE to view a chromless window with the incorrect encoding detected by Mozilla. There's something interesting I found with MS IE. Most of time, MS IE gets the encoding right at the first try (for the same chromless window for which Mozilla gets the encoding wrong). I think this means either of the following: A. Somehow the encoding detection of MS IE works better than Mozilla for some pages. (I'm sure there are cases in which the opposite is true) B. MS IE 'inherits' the encoding of the page from which a chromless 'child window' is fired up. That is, if the encoding of the parent window is used for child windows *without* the automatic encoding detection applied to child windows. On the other hand, Mozilla tries to detect the encoding of child windows from the scratch, which often leads it to come up with a wrong encoding because more often than not text-content of child windows is NOT long enough for a reliable encoding detection. If 'B' is the case, I think Mozilla may as well be modified to get a child window to 'inherit' the encoding of its parent window *by default* (of course, that should be overridable). With this implemented, the need for users to manually override the encoding of a child window via 'Character-Coding' menu would be reduced quite a lot. This does NOT mean that 'character-coding' menu is not needed in a chromless child window. It's still necessary. If 'B' is the case, I guess a separate bug has to be filed for 'enhancement'. Could anyone tell me whether that's indeed the case? If so, I'll file a new bug.
Jungshik, Mozilla does inherit the charset encoding setting from a parent window to a child window. Please have a look at: http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/navigator .js#276 http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/fastnav.j s#281 http://lxr.mozilla.org/seamonkey/source/xpfe/communicator/resources/content/cont entAreaUtils.js#59 Although I can't say, whether this works in chromeless state, I believe it does. You could help verifying with some debug dumps in your private build, if interested.
jbeta, Thank you for referring me to those. Indeed, inheritance of the encoding appears to be taken care of. Anyway, I put up a test page at http://jshin.net/~jungshik/i18n/jsnewwin.html. Can you try that page? The page and two 'child pages' linked there are in Korean(EUC-KR). My test with the latest nightly build (2001-08-07) as well as with M 0.9.3 seems to indicate that a chromless child window does not inherit the encoding of the parent window. When I opened a child window by clicking on either of two links there, they came up in ISO-8859-1 instead of EUC-KR.
hmm, you are right - this doesn't work. Both child windows are defaulting to Latin-1... Do we have a bug for that somewhere? I'll investigate, but please feel free to file a new one.
Thank you for testing it. I filed a new bug for this. It's bug 94281.
pushing out - I'll post some design suggestions/ideas this week
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Target Milestone: mozilla0.9.5 → mozilla0.9.6
jbetak- Maybe we could only put the "static" part and the "dynamic" of charset menu into the contextual menu without "auto detecotr submenu, customoization and the more submenu". This will make the charset menu a one level submenu with only 5-6 items there. And usually user will see the needed charse there since the static part and the dynamic part match most of the needed charset.
I agree - I was hoping to make it a little longer (like in mailnews) and have an extra item name 'Others...' or 'Customize...', which would allow additional interaction/customization if needed. Adding the bottom part of the charset menu (including the most recent and preconfigured/customized static encodings) would be probably most expedient. On a second thought: since users who require and use the charset menu will probably have it adapted for their regular use from the main menu, they probably won't really need any further customization in the submenu. This might really be the most expedient and (hopefully) acceptable solution. I'll come up with a patch and make some screenshots.
m0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7
*** Bug 105823 has been marked as a duplicate of this bug. ***
mpt, blake - would this (attachment 54577 [details]) be acceptable for Mozilla?
I hate to be nagging - but could anyone give this UI go-ahead? I'll start the r/sr process tomorrow.
jbetak's contract is up. Bulk move bugs to ftang
Assignee: jbetak → ftang
Status: ASSIGNED → NEW
give back to nhotta to research
Assignee: ftang → nhotta
Attachment #58166 - Flags: review+
Comment on attachment 58166 [details] [diff] [review] updated patch - nhotta could you please try it a prehaps give it r=? r=nhotta
Comment on attachment 58166 [details] [diff] [review] updated patch - nhotta could you please try it a prehaps give it r=? I'm concerned that we're adding even handlers to every menu item here, when we could be adding it to the toplevel menuitem (i.e. <menu id="browserContextCharsetMenu">)
MultiplexHandler(event) is added to "browserContextCharsetMenu" which is a top level. Are there event handlers attached to other item?
thanks for looking over this alecf; would this work better? <menu id="browserContextCharsetMenu" oncommand="MultiplexHandler(event)" onpopupshowing="CreateMenu 'browser');UpdateMenus(event)"/>
I think so - in any case the event handlers should end up in charsetOverlay.xul... I've added myself to the CC in case you want to attach a new patch...
Comment on attachment 58180 [details] [diff] [review] patch v 4 - menu event handlers moved to contentAreaContextOverlay.xul that has it in both overlays.. is that going to work?
Attachment #58180 - Attachment is obsolete: true
I think Juraj just forgot to remove the handlers from charsetOverlay.xul (they are not needed to be in charsetOverlay.xul). Alec, please review the last patch.
Comment on attachment 58630 [details] [diff] [review] Removed handlers from charsetOverlay.xul. yay, this looks right. sr=alecf
Attachment #58630 - Flags: superreview+
Checked in.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Huh, the contextmenu is still activated, after selecting 'Character Coding->Customize' in the context menu, but selecting the same menu item from the main menu works! 1) I don't have the menu items 'Auto-Detect' and 'More' in this menu, is this correct? 2) 'View->Character Coding->Auto Detect' is empty from the main menu. 3) Sub menu's in menu More are also empty and and there is a useless separator in the menu. -Neil.
And, both menus are not in sync, selecting one from the main menu adds an extra selected menu item in the context menu.
Please do not add items to the Navigator context menus without consulting the Navigator FE group. This area of the UI is under UE review at the moment and we are not accepting unplanned modifications to it. The approach used here is of questionable value. Loading the context menu up with items that are unavailable in circumstances where the top level menu is not available does not scale. Rather than considering these issues in piecemeal fashion, I recommend returning to the drawing board and considering what the web author has done - removing the user's menu bar. This disables more functionality than just the ability to change character coding. How do you address that? These are issues to be thrashed out *before* code is checked in. Because this code may represent an undersirable solution to this problem, and because it has arrived without notice during a time when we are trying to evaluate what we have, it has been backed out. Also, please consult with the Navigator FE group in the future before adding UI to our component. Reopening this bug as it is now an issue again.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
adding dependency to bug 75338, which is tracking context menu UI.
Depends on: 75338
No longer depends on: 75338
I agree with Ben's comment: "The approach used here is of questionable value. Loading the context menu up with items that are unavailable in circumstances where the top level menu is not available does not scale." Indeed, if we followed that approach we could end up replicating the entire menu bar in context menus someday. We don't want that. We want users to do be able to get at what's familiar to them, which would be to return the menu bar, and then access the item they already know in terms of location and context. thus we begin to promote a desired pattern for all instances with missing menus.
You might try this: add a single menu item to the context menu, to re-activate the menu bar, in case it is missing from a window! This way the user is always in control! Replicating the menubar item is just plain stupid! Another option is to add a short-cut to enable/disable the menubar. -Neil.
FYI: I have filed bug 112965 (RFE) for this issue. -Neil.
No... this is still a problem. Suppose we do add the option to restore the menu bar. There is still a problem with frames. I would like to option to change a frame's encoding directly via the context menu. Unless you add an option to put a menu bar on each frame (which doesn't sound right to me), you will have to add all frame-specific options (such as "View Frame Source", "Bookmark this Frame", "Open frame in new Window" or "Character Coding") in the frame's context menu. From the list above, only "Character Coding" is missing.
The top level menu item [could|should] operate on the focused frame.
*** Bug 113026 has been marked as a duplicate of this bug. ***
I fail to understand why we need to get the entire functionality of the menu bar in case the menu bar is unavailable. A lot of items, such as "bookmarks" and "Open file", are not context-sensitive; they can be done in another window which has a menu bar. "Character coding" on the other hand is context-sensitive. You cannot use another window to achieve the desired effect. And currently there is no keyboard shortcut to do this, so users have to entirely rely on charset auto-detection (some users don't even turn it on!). There are ocassions I have to use IE or Konqueror (both of which can change character encoding through context menu) to view certain web pages. And if "Edit page in composer" is important enough to get into the context menu, I don't see why "character coding" shouldn't. :p
I agree with Danny. This is importand enough to be added.
Ben, please see comment 49 - i18n team is and always has been soliciting UE reviews. What do you suggest they do when UI reviewers and FE module owners are not available or perhaps not interested? Several people have attempted to get this necessary functional addition into the product in the course of the past 8 months. Do you this this rate of pogress is acceptable? I personally don't... While the increased attention of late is great - would perhaps a discussion about some of the gating factors be beneficial?
I'm sorry, this is partly my fault. I got behind in my bugmail, so I didn't get to answer jbetak's question in comment 49 before the patch was checked in. The answer would have been `no, see my previous comments'. However, I don't think it's fair to complain that UI people are the gating factor here: I described the appropriate way to fix this bug way back on the 25th of *July*, and Ben gave instructions on how to implement it a grand total of nine minutes later.
> However, I don't think it's fair to complain that UI people are the gating > factor here: I described the appropriate way to fix this bug way back on the > 25th of *July*, and Ben gave instructions on how to implement it a grand total > of nine minutes later. One of the problems we have is that your proposal in Bug 10999 has not been agreed on by parties concerned in this issue. If we are depending on that bug for this and other bugs to be resolved, then we should probably settle the issues there first. This is unfortunate because I don't believe the proposal there is a good one to adopt. But we'll debate it there.
*** Bug 114333 has been marked as a duplicate of this bug. ***
>------- Additional Comment #67 From Ben Goodger 2001-11-28 17:45 ------- > >Please do not add items to the Navigator context menus without consulting the >Navigator FE group. First, ben@netscape.com is on the cc list since 2001-07-24 11:48:39 . Second, alecf@netscape.com gave a sr= . Is Alecf part of the Navigator FE group? Third, I have send out the requirment to the pixeljokeys@netscape.com mailling list on 11/7/2001 16:49:11. No body reply my mail and object to it. What is your definitation of "without consulting the Navigator FE group." ? >This area of the UI is under UE review at the moment and we >are not accepting unplanned modifications to it. >Also, please consult with the Navigator FE group in the future before adding UI >to our component. Please clearify the definitation of "consult with the Navigator FE group"
frank I work on embedding, not navigator FE. I've stated this before, but not clearly in this bug: I was super-reviewing the code, to verify that it was implemented correctly and I'm sorry that it ended up going in. I was working under the assumption that this was a feature to match a spec.
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! Moreover, in normal websites, it's also likely that a frame's encoding is wrongly set or not set because the author simply forgot to change it while he was using his "WYSIWYG" editor! So a context menu is essential to everyone. But I agree that it's not necessary to copy the whole charset menu / submenus to context menu. Just the usual charsets should be sufficient. One other thing, when I use the menu bar to change the encoding, Mozilla seems to reload every frame from the *server* instead of from cache. I can't remember in what situation this would happen, but it's surely very annoying.
sorry for my misunderstanding about alecf's group.
Target Milestone: mozilla0.9.7 → ---
Changing the encoding of individual frames is bug 63054, not this bug. This bug is a duplicate of bug 26353 regardless of whether bug 10999 has been fixed. Since Ben Goodger, Marlon Bishop, and myself agree on this issue (a truly miraculous circumstance), marking as such. (FYI, the reload problem is bug 17889.) *** This bug has been marked as a duplicate of 26353 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
Mark as verified due we have other bugs to handle this.
Status: RESOLVED → VERIFIED
*** Bug 137480 has been marked as a duplicate of this bug. ***
*** Bug 150655 has been marked as a duplicate of this bug. ***
*** Bug 146767 has been marked as a duplicate of this bug. ***
Reopen this bug. I propose a fix through context menu in bug 98395, but somehow it has a small problem. I didn't realize so much effort has been spent on this issue. Since there is not conclusion yet, I reopen this bug. I know some people is against adding item to context menu. No matter what the final solution might be, let's keep this bug open for discussion.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
shanjian, I believe marlon has signed off on the encoding menu inclusion -- after Kat explained how crucial this is for many CJK, Russian and other users. There might have been the provision that it we make it more intelligent, that the context menu entry won't appear for people surfing predominantly Latin-1 sites or perhaps people who have never opened the main menu encoding menu. I'm not sure how robust such a solution might be, perhaps it could be handled separately - after we get it checked in. Note that even mpt recognizes the usefulness of manually-controllable document encoding: http://mpt.phrasewise.com/ Here Mozilla has three simple flaws which would waste staff time in comparison with Internet Explorer, which would therefore make it more expensive for us to use than MSIE is. 1. We can’t put a “Zoom” button (or, preferably, “Smaller” and “Larger” buttons) on the toolbar, for the benefit of customers with vision difficulties. 2. We can’t put an “Encoding” button on the toolbar, for the benefit of Asian customers. 3. There isn’t a “Home” button on the toolbar, for quickly returning the browser to our home page when a customer has finished. Indeed, it’s not even an option (not that the existence of an option would be an excuse for the poor default).
1. it should always be possible to show the menubar. i've said it in one bug, i'll say it in another bug. 1' that solves this problem 2. it should always be possible to show the statusbar (and perhaps it should be possible to prevent web pages from hiding it) 2' IE3 and QNX Voyager let you change encodings using the statusbar.
timeless, Netscape 4.x and more recent versions of IE do this via the context menu. That's where people will start looking and that's where they expect it. Whether it's the optimal or most logical solution or not shouldn't matter, let's please the crowd for once instead of coercing it.
Timeless, suppose we have a frameset in which the left frame is in Latin-1 while the right one is in non Latin-1, say Big-5. If we use "encoding" in menu bar to use Big-5, if I'm not mistaken, it's the whole browser which is swapped to Big-5, ie the left frame is in Big-5 too. This is possibly not what we wanted.
Is this bug got ignored? There was a fix but rollback. but I don't think a fix is impossible or too hard. I think it is important to fix this for Asia users like me.
seak: it's not my job to design a correct ui for intl, but given how many times intl goes around breaking things, perhaps i should? ok, here's something that works: A. view>character coding... --this implies it brings up a dialog. B. f10 will always show the menubar (except mac where you can't hide it anyway) so far i've guaranteed that you can always get to the dialog. C. the character coding dialog will have two things: 1. a map of the browser window and all of its frames. In which it should be possible to: a. select framesets. b. ctrl-click to (un)select a frame. c. shift-click to select a frameset and all of its children. d. use <space> instead of {click} for b/c. 2. some way to select a character coding for the selected frame(s).
> but given how many times intl goes around breaking things, perhaps i should? timeless, could you elaborate on this a bit?
i'd rather not, let's worry about implementing something which ben@netscape.com would approve (perhaps my proposal) instead of reading this bug to see that no one pays any attention to the contents of this bug.
I agree. By the same token, it would be more constructive not to resort to finger pointing. People *are* paying attention to this bug; momoi-san worked literally overtime to get marlon sign off on a design that would work for most international users. I believe the only reason i18n wasn't able to move on this was something akin to a "political gridlock".
Re comment #96: Timeless, your proposal of dialog is very nice, but don't you think it's too much effort? I think putting the _whole_ "Character coding" submenu in context menu would need less effort, don't you think so? There was discussion about putting mostly used encoding, but I think a quick but suboptimal solution is a lot better than a perfect but never coming solution.
Sorry but I'm really getting impatient to know how this bug proceeds. Re #96: Timeless I'm using Netscape 7.1 and found that in a new menu-less window, even if I press F10, I still can't get the menu bar. So it's impossible to choose a correct encoding in this case.
Backing Seak here, in Mozilla 1.5 F10 has no effect in a chromless window, either. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
Is it that hard to add the charset menu in context menu? I think this feature also solve another bug that ask for a UI to switch charset in sidebar
It is THAT hard because it's (silly) policy-related not technical.
This bug is 3 years old. It has 8 votes, 5 dups and more then 25 people on the CC list and blocks another bug. This is not counting the number of times this issue has come up in international message boards. I hate useless comments in bugzilla as much as the next gal- but isn't it time we reach a decision about the proper way to fix this bug?
This bug is 3 years old. It has 8 votes, 5 dups and more then 25 people on the CC list and blocks another bug. This is not counting the number of times this issue has come up in international message boards. I hate useless comments in bugzilla as much as the next gal- but isn't it time we reach a decision about the proper way to fix this bug?
Ok, some clarification. In Comment 96, I meant: 1. It should not be my job to design intl UI. 2. Perhaps I should design a UI. 3. What followed was a UI design *proposal*. Someone will have to write code to make F10 show the menubar (B). Similarly someone will have to make a dialog which lets you select character codings for frames (C) which also does not exist today. And someone will have to connect the dialog to Character Coding ... (A). None of the things in comment #96 exist. I don't understand how anyone could reach (B) and not realize that it was in a series of wishlist items. At least (A) and (B) are easy to implement. (C) would obviously takes more work.
How about using the Page Info -> General to override the encoding? using this page should be fairly simple, as it is always accessible (via Accel+I) and always displays the charset. In addition, this would keep the context menu clutter-free. Another option (which I'm not too sure is technically possible) is to drag&drop a bookmarklet to set a specific character coding. Obviously, even if this is possible, it can only be regarded as workaround. Prog.
*** Bug 237750 has been marked as a duplicate of this bug. ***
*** Bug 245329 has been marked as a duplicate of this bug. ***
I also strongly support for a method to change the character encoding. While I'm not insisting on the context menu in particular, it seems to be the best solution known so far. I've read comments against deep context menus, but the guideline isn't meant to be that rigid a rule, and having one is far better than having nothing that you can do to change the character encoding and having to resort to other browsers just because of it. It works well, and MSIE has also been doing it. If a deep context menu is really a problem, we could put shallower item(s) in the context menu, popping up a dialogue box as necessary. Some people say that it should be resolved by enabling the user to regain the menu bar, but it doesn't always work well. I can think of three different situation where the character encoding is needed: 1. chromeless window 2. frameset 3. inline frame (introduced by the IFRAME element) The context menu solution can work in the same manner for all of these, but showing the menu bar would work only for 1 and I don't see how it could work for 2 or 3. The character encoding is a property of each document, not of each tab or window. I'm very disappointed to see that this bug, which is so crucial to users outside ISO-8859-1, has not been resolved for more than three years. I'd love to see some agreement and progress on this. And I propose to change the severity from minor to major, since it makes some pages (many pages, for some people) totally unreadable without giving the user any other options.
FYI, I've just found an extension adding this feature to firefox 1.0. It's at https://addons.update.mozilla.org/extensions/moreinfo.php?id=371&os=Windows&application=firefox&version=1.0&go=Go
Great! Really really great! Exactly what I was looking for for the past 4 years! Could it be included in as a compiled function or as an extension in the main setup?
Blocks: 240301
I'm confused. Comment #64 says checked in. So why the bug is still not fixed? Do we need a new patch? A fix is probably trivial. The only reason to refrain it from being fixed seems "we do not need it because it wasted precious real estate", which is kind of unjustified due to the population demanding the feature. (This bug has its popularity in non-English speaking community, which can't be judge exactly by the number of CC's and votes since a portion of them do not understand English.)
This isn't still fixed in SeaMonkey because it was backed out, see comment 67.
ic, it is for SeaMonkey. I suppose Firefox can implement the feature on its own. Probably bug 240301 depending on this bug is a mistake?
I would say bug 240301 and this one are talking about the same thing. Anyway, I've raised the severity to get more attention. This raise is justified because for some websites, Firefox failed to detect the correct encoding to use. For example, sometimes it would use Big5 (for traditional Chinese) while the site is in simplified Chinese, and sometimes the opposite. All these give very poor experience to simple end-users. And the worst, as has been discussed again and again in this bug, is that sometimes there's no way to change the encoding: 1. because the menu isn't available, or 2. because of frame OK, I'm not going to repeat the argument again. As I've suggested in comment #113, we could include the "Right encoding" extension (add-on) in the setup, just like "DOM Inspector" and "Talkback". Of course, credit must be given to Kim Go Myoung, the author of this extension.
Severity: minor → major
With the release of Firefox 3.0, this add-on is no longer compatible. And it seems that the author no longer maintains it either! Of course, it's possible to modify the version 0.2.2 to make it work with FF3 (digression: change the install.rdf within the XPI file so that the maxVersion for Firefox becomes 3.0.0.*) but I don't think it's correct to assume every user knows how to do so! So, please, either someone takes the ownership of that add-on and modify it, or incorporate it into Firefox as one of the default add-on.
(In reply to comment #118) > Of course, it's possible to modify the version 0.2.2 to make it work with FF3 > (digression: change the install.rdf within the XPI file so that the maxVersion > for Firefox becomes 3.0.0.*) but I don't think it's correct to assume every > user knows how to do so! Easier possibilities: either (a) have Nightly Tester Tools or MR-Tech Toolkit installed first, and tell them to ignore version incompatibility; or (b) probably least safe: set extensions.checkCompatibility to false in about:config. Of course, all of these (including the install.rdf maxVersion bump) will only work if the sole incompatibility is in which versions the extension "claims" to support. If a "true" incompatibility arises (at the code level) then the only way to make it work will be to patch the extension code.
(In reply to comment #119) > > Easier possibilities: either (a) have Nightly Tester Tools or MR-Tech Toolkit > installed first, and tell them to ignore version incompatibility; or I've no idea what they are. But I don't think they're something that EVERYBODY would (know how to) use. >(b) probably least safe: set extensions.checkCompatibility to false in > about:config. Besides all those considerations you stated after that, this method is only good for one Firefox installation. However, if the xpi file is changed, I could give it to my friends and they could use it in UNLIMITED number of times. Nevertheless, whether your solution or my solution, they aren't supposed to be known by EVERY USER (well, unless every Firefox user in the world has a friend of some tech savvy guys like you and me. But such assumption is very unlikely to be true in this world)
(In reply to comment #120) > (In reply to comment #119) > > > > Easier possibilities: either (a) have Nightly Tester Tools or MR-Tech Toolkit > > installed first, and tell them to ignore version incompatibility; or > > I've no idea what they are. But I don't think they're something that EVERYBODY > would (know how to) use. They are extensions, available at addons.mozilla.org. I used them long before I "dared" to unpack, modify and repack the .xpi. > > >(b) probably least safe: set extensions.checkCompatibility to false in > > about:config. > > Besides all those considerations you stated after that, this method is only > good for one Firefox installation. However, if the xpi file is changed, I > could give it to my friends and they could use it in UNLIMITED number of times. about:config is available in Firefox, in SeaMonkey, as the "Config Editor" in Thunderbird, etc. I suppose it would be available on any app which could use the Right Encoding extension. > > Nevertheless, whether your solution or my solution, they aren't supposed to be > known by EVERY USER (well, unless every Firefox user in the world has a friend > of some tech savvy guys like you and me. But such assumption is very unlikely > to be true in this world) > Yes, that's the problem. Even making a version-bumped version of Right Encoding available somewhere on the web would probably only be a stopgap method -- available to the people savvy enough to find it, and only as long as the browser hook doesn't change.
QA Contact: amyy → i18n
Blocks: cuts-control
We've missed the 10-year anniversary for this bug! What a shame! LOL
Telemetry shows that this feature is used extremely rarely. It is not worthwhile to polish this feature further.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: