63054 - Character Encoding menu should affect currently focused frame

Status: RESOLVED WONTFIX

(Core :: Internationalization, defect, P4)

Description

[Katsuhiko Momoi]

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.

Comment 1

[bobj]

Some embedding applications might put the current character coding menu into
the context menu, so there might be a conflict or confusion here...

Comment 2

[bobj]

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.

Comment 3

[kill this account]

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?

Comment 4

[Katsuhiko Momoi]

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?

Comment 5

[timeless]

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.

Comment 6

[kill this account]

This is an interesting idea but ...

  do we *actually* have anyone complaining about this or asking for this?

Comment 7

[Frank Tang]

move all cata's bug to ftang

Comment 8

[Frank Tang]

timeless- can you produce a patch for demo (prototype) ?

Comment 9

[Frank Tang]

nhotta- can you talk to timeless about this ?

Comment 10

[nhottanscp]

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.

Comment 11

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 12

[Jesse Ruderman]

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).

Comment 13

[timeless]

Attachment: very old archive.

Comment 14

[Katsuhiko Momoi]

> 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. 

Comment 15

[kill this account]

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.

Comment 16

[Jesse Ruderman]

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).

Comment 17

[bobj]

Another data point: IE 5.5 has an Encoding submenu entry in its context menu.

Comment 18

[Ilya Konstantinov]

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.

Comment 19

[Shoshannah Forbes]

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

Comment 20

[kill this account]

per ftang's suggestion reassigning to Juraj

Comment 21

[[e-mail] (away - not reading bugmail)]

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.

Comment 22

[Blake Ross]

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.

Comment 23

[[e-mail] (away - not reading bugmail)]

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.

Comment 24

[[e-mail] (away - not reading bugmail)]

Ops, I forgot to add bug 70830 to the dependency list as originally intended.

Comment 25

[[e-mail] (away - not reading bugmail)]

pushing out - I'll post some design suggestions/ideas this week

Comment 26

[[e-mail] (away - not reading bugmail)]

pushing out once more...

Comment 27

[Frank Tang]

move to m0.9.7

Comment 28

[Frank Tang]

jbetak's contract is up. Bulk move bugs to ftang

Comment 29

[Frank Tang]

give to nhotta to research. Mark it as m0.9.8

Comment 30

[marlon bishop]

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.
  

Comment 31

[Ilya Konstantinov]

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.

Comment 32

[bobj]

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.

Comment 33

[Katsuhiko Momoi]

> 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. 

Comment 34

[Katsuhiko Momoi]

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.

Comment 35

[Blake Ross]

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."

Comment 36

[Blake Ross]

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)?

Comment 37

[Ilya Konstantinov]

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.

Comment 38

[nhottanscp]

Reply to Bob's comment #32,
I think a focused frame can be set by charset menu (see bug 43529, 112793). 

Comment 39

[Stanislav Malyshev]

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.

Comment 40

[Hixie (not reading bugmail)]

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?

Comment 41

[Jungshik Shin]

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.  

Comment 42

[Hixie (not reading bugmail)]

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.

Comment 43

[loadrunner]

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

Comment 44

[Katsuhiko Momoi]

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. 

Comment 45

[Katsuhiko Momoi]

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. 

Comment 46

[Hixie (not reading bugmail)]

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.

Comment 47

[Yuying Long]

Is this a same problem in bug 98395?

Comment 48

[nhottanscp]

Bug 98395, I think shanjian is working on the backend. We can keep this for
front  end issues.

Comment 49

[marlon bishop]

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

Comment 50

[Hixie (not reading bugmail)]

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.

Comment 51

[Ilya Konstantinov]

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).

Comment 52

[Yuting Kuo]

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.

Comment 53

[Henry James]

I'm sorry to step in so late, and since the discussion of this issue is spread
over several bugs, I'm not sure to have the complete overview. Anyway, it seems
the decision has not yet been made, so I want to bring some argument *against*
the suggestion "Character Coding menu should affect currently focussed frame". I
strongly support context (sub)menu.

Ian says in comment #40:

> 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 would guess Ian only visit "normal" websites most of the time. I myself have
seen different sites where you *cannot* simply focus the frame by clicking it:

1. Some "dynamic" codes (Javascript, for example) reset the frame focus so it
does not stay where I set it.
2. Javascript of the site deactivate or rewrite mouse click function.
3. The whole frame contains one single image which takes the entire frame and,
at the same time, is a link. When I click it, I would be carried away.
4. The whole frame contains a Java applet which takes the entire frame and react
to mouse click somehow.
5. Some other problem I cannot name right now.

OK, problem 2 and 4 could also exist with context menu, but problem 1 and 3
would not. And above all, if the char encoding in main menu only affects cuurent
frame, how am I supposed to change the encoding for all frames? Don't tell me I
will have to change each of them individually then!

While being a UI minimalist myself (my Windows desktop only contains "My
Computer", "My Network" and the "Recycle Bin", for instance), I cannot really
understand the outcry about one (substantial) context menu entry more. I am also
strongly against hiding this context menu entry by default.

Then the comment #49 of marlon about "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

Pardon me, what is so "special" about Latin-1? Why is Lanin-1 considered default
and the world divided in "Latin-1" and "non-Latin-1"? Make no mistake, I only
use English (e. g. Latin-1) software myself, but this is surely not "default by
natural"!?

Sorry, I do not intend to offend anyone here, but I felt somehow offended
reading some of the comments. What does "local user" mean? Is "local" another
word for "(only) English speaking" in UI jargon? How can anyone suggest there
being hardly people (or situation) needing (how badly ever) per frame char
encoding? There isn't actually any figures you rely on, is there? Personally, I
never believe it's only "5%", that's for sure.

Comment 54

[Christian :Biesinger (don't email me, ping me on IRC)]

>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. 

Comment 55

[Christian :Biesinger (don't email me, ping me on IRC)]

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.

Comment 56

[loadrunner]

"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.

Comment 57

[loadrunner]

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. 

Comment 58

[Christian :Biesinger (don't email me, ping me on IRC)]

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.

Comment 59

[[e-mail] (away - not reading bugmail)]

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.

Comment 60

[Henry James]

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.

Comment 61

[Henry James]

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...

Comment 62

[Tony Mechelynck [:tonymec]]

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.

Comment 63

[Henri Sivonen (:hsivonen)]

Telemetry shows that this feature is used extremely rarely. It is not worthwhile to polish this feature further.