At present we can either change all the frame encodings at once but cannot do so for each frame. This bug has been filed to request that we create a contextual menu to set per frame encoding. In addition, the main Character Coding menu should be sensitive to where the focus is and change the menu name from "Character Coding" to "Frame Character Coding". Changing the entire framset encoding is covered by Bug 43529.
OS: Windows NT → All
Hardware: PC → All
Summary: Should have a contextual menu for each frame → Use context menu to change encoding of individual frames
Some embedding applications might put the current character coding menu into the context menu, so there might be a conflict or confusion here...
I take back my last comment about "conflict" since the original description used the term "Frame Character Coding", but still need to address usability and potential confusion of the UI if we have both menu items in the context menu.
for a frameset produced from one site this feature is probably not needed: the page and frames will either all be the same encoding or they will have an encoding tag. the case where this might be useful is in a site where one frame causes a second frame to be loaded from a remote site (think of a search engine where the target page is loaded into a sub frame when the link is clicked on) are we seeing the happen alot? Will separate frame encoding menus be confusing for the user?
I think of this bug as a way to provide an override capability. It is true that most sites will have all the frames with the same encoding. But each frame is an object and ech object can carry its own encoding. And, 1. Some frames may not indicate any encoding either in the document or via HTTP. 2. An encoding indicated in one or more frames may be erroneous. And also there is a possibility that bstell mentions, i.e. loading a frame from remote site. We have no easy way to cope with these right now without changing the encoding on every frame. What do others think of this?
i love this mess because i can solve it with cascading context menus. but mpt will kill us all if i try. if anyone is interested in a demo, contact me on irc.
This is an interesting idea but ... do we *actually* have anyone complaining about this or asking for this?
move all cata's bug to ftang
Assignee: cata → ftang
timeless- can you produce a patch for demo (prototype) ?
Status: NEW → ASSIGNED
Priority: -- → P4
nhotta- can you talk to timeless about this ?
I think most of the problems will be resolved when bug 66130 is fixed. Is there a bug to have a context menu for charset encoding? When we do that, we should make it frame base.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Changed QA contact to firstname.lastname@example.org.
QA Contact: teruko → ylong
I don't think encoding should be a context menu item, since it would be the only submenu of the context menu, and since (I'm guessing) it's used about as often as view source (which may be removed, see the third attachment on bug 26939).
> I don't think encoding should be a context menu item, since > it would be the only submenu of the context menu, This is not true. Just look at Comm 4.7 and see how many items are on the contextual menu per each msg displayed. > and since (I'm guessing) it's used about as often as view > source (which may be removed, see the third attachment on > bug 26939). I again disagree with this assessment. I use a contextual menu for msgs for adding addresses to Adrress Book, rot13, copying, moving, etc. Too many function to count. View Source is an essential function that is needed for advanced users. As far as I know both Messenger and Outlook Express provide this function in one way or another.
For western users viewing western pages the encoding menu is probably never used. BUT for other users the ability to set the encoding is *CRITICAL*. It is not at all comparable to view source which at best is just a convenience.
I didn't mean to imply removing the option to change the encoding altogether, I just meant that I didn't think it should be on the context menu. There would still be a Frame Content Encoding option on the View menu that would apply to the focused frame. That's similar to what mpt proposed in bug 26939 (with the goal of keeping context menus short).
Another data point: IE 5.5 has an Encoding submenu entry in its context menu.
Jesse, I disagree. On sites such as www.orange.co.il, which open menuless windows with unset encoding (while the actual encoding is ISO-8859-8), there's absolutely no way to change the encoding of those pages on the fly (unlike Internet Explorer and Konqueror), making the site useless. For that matter, it's impossible to view the pages' source either. I understand the UI people concerns with context menus, as I've seen application which've taken them too far, but that's not the case! If you feel there's a need to make an English-only speaking newbie's experience easier, provide a Preferences option for simplified menus, and maybe even an "I speak English only" switch.
I want to add my voice to the people who want this menu. It is very needed, espcially for frameset where each frame uses a diffrent encoding. For example, see: http://www.seelive.net/frameset/frameset_about.htm Click on the link to the article at "thenet" web site- the inner frame uses logical Hebrew, while the rest of the frameset is visual Hebrew
per ftang's suggestion reassigning to Juraj
Assignee: nhotta → jbetak
Status: ASSIGNED → NEW
accepting, targeting 0.9.4, marking dependency on bug 70830. Since we need to redesign the charset menu to be permitted to use it in the context menu, we might only be able to come up with a commercial-only solution for the short- term. I might create a Bugscape bug for that eventuality.
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla0.9.4
This should not be added to the context menus without input from UI folks. I invite you to take a look at our current context menu for an element in a frame, http://bugzilla.mozilla.org/showattachment.cgi?attach_id=27906. 26 items. Also take a look at http://bugzilla.mozilla.org/showattachment.cgi?attach_id=43887. IE has it in their context menu. Great implementation, isn't it? See also bug 70830.
I believe that I did not convey any intention to include this into Mozilla or the commercial tree w/o an UI review, so please do not police this bug. I think our collective energy can be more wisely spent than that.
pushing out - I'll post some design suggestions/ideas this week
Target Milestone: mozilla0.9.4 → mozilla0.9.5
pushing out once more...
Target Milestone: mozilla0.9.5 → mozilla0.9.6
move to m0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7
jbetak's contract is up. Bulk move bugs to ftang
Assignee: jbetak → ftang
Status: ASSIGNED → NEW
give to nhotta to research. Mark it as m0.9.8
Assignee: ftang → nhotta
Target Milestone: mozilla0.9.7 → mozilla0.9.8
this appears to be one of those common UE dilemmas where: 70% of users depend on this feature 0% of the time 25% of users are reliant on this feature maybe 60% of the time 5% of users demand this feature 100% of the time a minority percentage perhaps can't live without it, however it's the substantial majority who must carry the burden of extra menu items never used. Ideally these types of features should not appear by default in Western/US/ or English bound browsers because it's making menus longer and more complicated. There's a similar argument however for other locales with localized Netscape client. Nevertheless we should be clever enough to query the OS for presence of multi-encoding-like features, or simply create a pref to toggle these items in the menus (context and main). By default these should be absent for English markets. Since i am generally new to internationalization issues, i am not yet familiar with encoding needs of our users in other locales, and i'd yield to any data or authority which provides different case(s). Perhaps there'd be ways to use overlays. Provide them for localized client where a locale has been identified to need faster/more frequent access to these features based on relative obscurity of sites presented in the language of that locale.
There's a logical need for encoding selection to be per-frame -- but I agree that it clutters Mozilla's already-overclutterd popup menu. I bet most users never use the Form prefilling menus, for instance. Avoiding the encodings issue is saying 70% of the computer users know English and only English - which I'd speculate, is wrong. Users reading most languages other than English and some European languages face issues of unspecified or mis-specified encodings all the time. A possible solution is to make internationalization menus as preferences toggle, but frankly, this is too much of a US-is-the-center-of-the-world approach. As if having ISO-8859-1 as the default encoding wasn't enough -- now they want to take away our access to an essential feature we need to read different language pages. If it hurts people so much, prefs could have an option to declutter menus (removing developer options like View Source, form filling options and internationalization options), but by default - "Set Character Coding" should be present. Save the helpdesk people the hassle.
Many items in context menus are convenient ways to access existing functionality (e.g., back, forward, add bookmark, save, view source), but there currently is no way of changing the charset coding of frames or chromeless windows. Are there better alternatives to context menus for providing this functionality? Whether we provide a solution via context menus or some alternative, we should provide a solution. Static framesets with content from the same site will probably not need this functionality. But there may be pages which load an external URLs or create dyanamic content for a frame. In these cases, the encoding and tagging of the page may not be determined. For example, most Japanese pages are encoded in SJIS, but Yahoo Japan serves most of its pages unlabeled and encoded in EUC-JP. So if a Japaneses SJIS page loads a frame with a Yahoo Japan page, it might not be displayed correctly and would need the user to override the encoding of that frame.
> Are there better alternatives to context menus for providing this > functionality? Whether we provide a solution via context menus or some > alternative, we should provide a solution. I agree with this. Not having a way to correct per frame encoding contextually or otherwise makes Mozilla unfriendly to international users. It is needed. If cluttering up the menu is such a concern, then, make it an optional addition. In any case, don't let this request dragged out just because we are undecisive about how to approach this problem. There are only a few approahes to this. Like IE 5/6, provide contextual menu per frame or make the main menu be sensitive to where the focus is and present what amounts to a context- dependent menu. I don't think people who don't face this type of problem regularly understands how important this is for non-Latin 1 worlds. I believe this is assigned to i18n engineering for a reason. So, let's not impede much needed work.
By the way, already more than 50% of the net users in the world are living in non-English world and percentage of non-Latin 1 users are rising dramatically. The arugument of about "so many percentage of users ... " is laughable, to be honest with you. Please stop thinking locally and start thinking globally.
Even if the existence of this item is justified (and I don't see any convincing evidence that it is), it was not implemented properly. For starters, it certainly should not appear for every element in the page. Next, we could certainly be smarter about when we show it. What's wrong with only having it in the frame context menu, unless the menubar is hidden, in which case it could be shown in the page (and only the page) context menu too? Again, this is not to say I think this menu should be there. I agree with Marlon and Ben that adding items to context menus to account for hidden chrome does not scale well. I'm merely pointing out that whatever your position on the existence of this menu, it was still checked in in an incorrect form. So backing it out was not "impeding much needed work."
Also, with regards to > Not having a way to correct per frame encoding contextually > or otherwise makes Mozilla unfriendly to international users. Yes, but having this in all builds makes Mozilla unfriendly to local users. This, I think, was one of Marlon's points. Not only does it add another item to the context menu, but a submenu in a context menu is generally terrible practice. Matthew has a telling picture that shows why. > I don't think people who don't face this type of problem regularly understands > how important this is for non-Latin 1 worlds. We probably don't. But instead of calling our response 'laughable', time might be better spent explaining the situation to us, and outlining possible alternatives to a context menu submenu for everyone. > I believe this is assigned to i18n engineering for a reason. Engineers don't always make the best UI designers. Marlon has expressed interest in hearing more about the needs of international users to make a more qualified recommendation; I'm also curious as to whether Matthew or Jennifer have any input (cc'ing)?
I also wanted to outline that, while missing "View Source" or "Edit Page" from the frame's context menu might stop a user from doing certain operations with a page (when the chrome is hidden), missing "Set Character Coding" from frame's context menu might make pages totally unusable to begin with (unreadable). I think the second takes more priority.
Reply to Bob's comment #32, I think a focused frame can be set by charset menu (see bug 43529, 112793).
I agree with Ilya. There are a lot of items which are not necessary for the browsing experience per se in frames, such as "open this page in composer" (how many pages from other sites do you edit daily and for how many of them you don't know the URL to open them directly?), "send this page" (how many lone frames without encompassing URL you send daily?), "view stored data" (you can perfectly do it from "Tasks"), view page info (why you need it in each frame's context menu?), etc. But this item is really vital for browsing experience, because if the page is shown in wrong charset and you have no way to change it - you have absolutely no way to do anything with it. The rest of the menu is just useless then - you have to stop your browsing here, because the page cannot be read. So if you have to choose between not providing some functions which are, while being very useful, somewhat rarely needed and non-vital for browsing experience, and providing functions which are critical for the browsing, the choice should be clearly the latter. Context menu bloat is bad, but being unable to read the pages is much worse. With the former you get imperfect browser, with the latter you don't have any browser at all. As for focusing - I'm not sure that the unexperienced user should be bothered with knowing what exactly the focus is and where it is now, especially that there is no real way to see where the focus currently is. And at least in 0.9.6 release I had no success in setting charset individually to frames. Charset always is changed for all frames, whatever I do.
I would propose the following UI: 1. For the case where the main menu bar is missing, fix bug 69099. 2. Make the main menu's Character Coding item apply to the current frame if one has direct focus (dotted border). Note that focussing the frame is easy (just click on it -- users will know how to do this if they know how to get the context menu up, since it is a prerequisite for getting the context menu). I agree that this feature is important. I don't think that a context menu is good interface design. For QA purposes could we have a dozen or so framed pages showing this problem?
Whiteboard: need test pages showing the problem for QA
I just stumbled upon another page with different encodings used in different frames in a frameset. It's at http://www.korean.go.kr/linksite/linksite.html The left frame is in EUC-KR without metatag or http header to indicate that while the right frame is in UTF-8 with metatag to say so. Mozilla is getting the title from the left frame interpreted as in UTF-8 so that the window title bar gets screwed up. I understand the concerns of UI people, but this issue cannot be dragged on indefinitely. This is *very very* critical for those who need to view non-US-ASCII web pages. I'm using US-ASCII instead of English on purpose. Even for English pages, this is often necessary because sometimes they(I know from my own experience) have to switch between ISO 8859-1, ISO 8859-15, Windows-1252 and UTF-8. Please, don't say that US-ASCII(the intersection of all four encodings) is sufficient for English. There are tons of English web pages in Windows-1252, ISO 8859-1 or ISO 8859-15 and UTF-8 with characters outside US-ASCII. > Yes, but having this in all builds makes Mozilla unfriendly to local users. I'm afraid calling those who never need to view pages other than in US-ASCII 'local' users is pretty parochial. Local users in the US may not need to view pages other than in US-ASCII (even that is doubtful as I wrote above), but local users in China, Russia, Japan, Korea, Israel, Vietnam, Egypt, Ethiopia, Turkey and most of Europe do need to view pages in multitude of encodings. > This, I think, was one of Marlon's points. Not only does it add > another item to > the context menu, but a submenu in a context menu is generally terrible > practice. Matthew has a telling picture that shows why. I'm not saying context menu is the only way to go (for frames in a 'chromed' window, making view|character coding work on the focused frame seems to be a good solution. for chromless window, it gets complicated), but I'm just wondering if it would be so much a problem for US-ASCII users to add character coding submenu to context menu if they never never use it as you wrote? Doesn't it only become a problem when it is actually used? If I'm right in this (I may well be wrong), I don't think your argument that having this in all builds makes mozilla unfriendly to US-ASCII users stands.
Good example page. Having played with this, I am now convinced that my proposed UI is better (for people using it) than a context menu option. Our current behaviour (which appears to be changing either the root frame or all frames at once depending on the time of day) doesn't seem very useful.
Ian, mpt, marlon, ben: before engaging in further religious disputes over new context menu items and the appropriateness context submenus, please consider that a random sampling of popular commercial products shows that e.g. Quicken, Photoshop, Outlook and Visual Basic all use the UI approach the i18n team is proposing. While nested submenus are not as widespread, their presence in IE surely reflects a real and quantifiable need. While their particular choice of UI design might not be the best or most imaginative, flat context submenus seem to be much less controversial. I'd support the requirement to hide the charset coding context menu item from Latin-1 users. This could be accomplished e.g. by one or a combination of the following criteria: 1) currently loaded document is encoded in Latin-1 2) browser cache cache does not contain at least one non-Latin-1 document 3) the main charset menu has never been invoked
In comment #42, Ian says > Our current behaviour (which appears to be changing either the > root frame or all frames at once depending on the time of day) > doesn't seem very useful. There are bugs outstanding for the current behavior. When the focus is on the root frame, it is supposed to change all the encodings of all the frames with one change. Yet there are some sub cases which do not work lke that right now for reasons other than focus. If it works according to the test specs that the Netscape i18n team created, you will see consistency in behvaior in cases with no frame or with frames. The 2 bugs that concern this behavior will be fixed in due time. It has always been part of the plan to make frame-dependent encoding change to work properly whether it is via context-dependent menu or via the main menu via the focus shift. It just has not been implemented. if we settle this UI controversy quickly we can really serve users' needs faster.
Personally, either the contextual menu or the focus-dependent main menu is OK for me. I would take the approach that can be implemented more easily. I would drop all the purity aruguments that have been going on without much merit. The length of submenus and steps it takes to change contextual menu item is a largely bogus argument. In a huge majority of cases (I would venture to say over 95% of the cases of real users trying to display real web pages as opposed to some hypothetical cases), for both IE and Mozilla, users will only have to use 3 steps to change frame encodings. One to focus and bring up the contextual menu Two to choose the Character Coding menu Three to select an item on the first tier of the menu which contains user's frequently used character coding items. ** It is truly unnecessary to argue about the more submenu because that part will not be used in a huge majority of cases. We know this from the last 2 years of experience with this menu by testing and by listening to many users who use this menu regularly. Even if in some rare cases, the user has to use it to correct the problem. The next time on it will be on the cached list on the first tier. I think it is best to ask the assigned engineer which would be easier to implement and with less subsequent complications, and go with that choice.
loadrunner: I am not overly concerned about the Latin1-only users. I am more concerned with getting a decent UI for the bigger fraction of users who _do_ need a feature to change character encodings. momoi: Since whether or not we do this via a context menu we will still have to fix the main menu implementation, it would seem that not doing this via a context menu will be the solution that is quickest to implement.
Is this a same problem in bug 98395?
Bug 98395, I think shanjian is working on the backend. We can keep this for front end issues.
In my previous comment, i admited that i could not present a good case for the multi-lingual user's encoding practices. Which is why I was willing to yield to the international authority on the subject, Katsuhiko Momoi . I am now convinced that this could be handled through menus and focus shifting, but that it would be helpful as a shortcut as since it's usefulness has been made apparent here. therefore once we get the implementation fixed, i suggest adding these items to context menus when a proposed Multi-Encoding Bidi support switch is set. This switch may be located either in a pref panel, or in the view menu. I'd support the requirement to hide the charset coding context menu item from Latin-1 users. This could be accomplished e.g. by one or a combination of the following criteria: 1) currently loaded document is encoded in Latin-1 2) browser cache cache does not contain at least one non-Latin-1 document 3) the main charset menu has never been invoked i have posted the 2nd draft to the Context Menu Revision 2 document located: http://mozilla.org/projects/ui/communicator/framework/contextmenus/cmrev2-2.html
I am now a frequent user of the character encoding menu, and I can now say from first hand experience that a context menu would not be significantly more convenient. Thus, changing the summary to match above comments.
Summary: Use context menu to change encoding of individual frames → Character Coding menu should affect currently focussed frame
Whiteboard: need test pages showing the problem for QA → [Hixie-P0]
This bug is not about convenience, but about the mere possibility of changing a page's / frame's encoding while the main menu is missing (in a window.open-created window).
Replying to Comment #51 it is very common for a frame in a page to be set to the wrong encoding. It is not possible to change a single frame's encoding at the moment and context menu is the only viable way to achieve this. In addition, some pages, after refreshing, will lose their contents (expire) and the page is always refreshed after changing encoding from the menu. e.g. reading a message on web mail service.
>Why is Lanin-1 considered default RFC 2616 (HTTP 1.1), Section 3.7.1: > When no explicit charset > parameter is provided by the sender, media subtypes of the "text" > type are defined to have a default charset value of "ISO-8859-1" when > received via HTTP. Data in character sets other than "ISO-8859-1" or > its subsets MUST be labeled with an appropriate charset value.
two more things: the context menu already has a submenu (imho looks so ugly...). a second one will look even more crazy, and would be necessary for the charset submenu. and: given a well-configured server, or only a well-written page, there is no need whatsoever to change the charset of a page. one more thing re latin1: another reason why it's so widely used is probably that most developers are using it.
"Given a well-educated person, or only a well-written text, there is no need whatsoever for a spellchecker..." Quite obviously, a spellchecker would only clutter the UI and there shouldn't, isn't and won't be any justifiable use for it. Oh well. I have to say that I applaud Henry for his concise posting, which restates the real-world situation and the need for this functionality. Both Netscape 4.x and IE have had this context menu entry for ages. It would be interesting to see whether Opera has done the same. I believe that it’s reasonable to assume that commercially developed and viable products cannot afford to waste money and bandwidth on esoteric and marginally beneficial things or they won’t last very long. However, I do agree 100% that the UI implementation should be non-invasive and target only the locales and users who are most likely to benefit from it once we finally all agree to put it in.
Christian, ich frage mich sowieso, wie Du in Deutschland überhaupt von diesem Feature gebrauch machen könntest. In China, Japan oder Rußland ist die Lage allerdings dank historisch bedingtem Codierungswirrwarr und daraus resultierendem Mangel and (Codierungs-)Klarheit schon ganz anders.
loadrunner, I did not say that I could make any use of that feature. (but it is sometimes useful). also, I think that if server administrators can't configure their server right, that's their problem. you should not penalize all users for it. this is so off-topic for this bug... I will stop commenting here about an unrelated issue.
I wholeheartedly agree with your last comment Christian. And let me point out why: 1) I believe it has been agreed that there is no need to offer this functionality to users surfing predominantly Latin-1 sites. This could be determined quite reliably from a number of Mozilla settings and other factors. 2) I also believe that Mozilla's quirks mode is in itself an admission that the tail can't really wag the dog. Mozilla is a content viewer, not a religious evangelization tool. There will always be clueless server admins or website coders why penalize the users for it? 3) From what I've seen, especially in Japan and China, it's not just a matter of carelessness. The need for a charset override stems from the use of competing and complementary encodings. And thanks to the liberal use of IFRAMES they are oftentimes mixed and matched on a site. It can be a real nightmare. Let's don't oversimplify, let's stick to the facts.
Allow me to point out that wrong char encoding/decoding is not just a thing of server "misconfiguration", it's actually more about the lack of an effective algorithm to recognize char encoding automatically. In CJK, for example, it is often theoritically not possible to recognize the encoding of a text for sure. All there is are heuristics. Now a freak like you and me could simply specified what exact char encoding his text is using, but a normal user doesn't even know what char encoding is. So he just writes his text, send it to the server, and the server may guess the char encoding. Actually, the server doesn't. Not this server which receives the text. Commonly it's the unpleasent duty of the other server which displays the text later to recognize (i. e. *guess*) the encoding. And because this is so difficult, most systems does not even try. Somewhere in this or a related thread someone mentioned web mail systems. Let me just take Yahoo! mail, whose web interface is one of the best. Not even Yahoo! mail would (try to) auto recognize the char encoding of the mail it is displaying, but at least you can set it manually without problem (which I can't say for the majority of free web mail services). In fact, I don't know one single web mail service with an auto char encoding recognition. And even if one were there, it can impossibly be correct every time. Now, if the viewer of a text without an explicit char encoding specification is again a "normal user", he is f*cked up. If not, he should have the chance to personally do what is not (yet) a natural task of a (current) computer system - pattern recognition, in this case, guessing the char encoding.
Btw, could someone please tell me what is so "ugly" about a submenu (which isn't opened anyway because you don't use it) compared to a normal menu entry? It is simply beyond me. For German users: Noch nie ueber CP437 bzw. CP850 gefluchtet? Noch nie einen Text mit einer *Mischung* dieser beiden gelesen, wo Tabellenlinie zu "Ae" wird, andereseits aber das Copyright-Zeichen mutiert? In einem solchen Fall kannst du nur zwischen den beiden Kodierung hin- und herschalten. Nicht schlimm, es sind ja nur Tabellenlinien und Copyright-Zeichen. In Japanisch waere es aber ganzer Bloecke von Text...
Summary: Character Coding menu should affect currently focussed frame → Character Coding menu should affect currently focused frame
Summary: Character Coding menu should affect currently focused frame → Character Encoding menu should affect currently focused frame
Assignee: nhottanscp → nobody
I see in various comments above an opinion that there ought to be no character encoding context menu in the en-US Latin1 world, but only in versions of the browser for more "exotic" locales. I beg to differ: the fact that I happen to prefer English (US) *menus and messages* doesn't mean that I'm not interested in other languages and writing systems for the *contents* of web pages. When the whole page uses a single charset, I can of course use the View menu, even if the HTTP headers don't reflect the page's charset correctly. But what about framesets where each frame might be in a different charset? I'm going to vote for this bug. Please do _not_ limit its scope to non-Latin or even non-English locales.
Telemetry shows that this feature is used extremely rarely. It is not worthwhile to polish this feature further.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.