Closed Bug 70830 Opened 24 years ago Closed 8 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 → 8 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: