Closed
Bug 70830
Opened 24 years ago
Closed 9 years ago
Can't change page encoding in the windows without menu & toolbar
Categories
(Core :: Internationalization, defect, P4)
Core
Internationalization
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: anoripi, Assigned: nhottanscp)
References
(Blocks 1 open bug, )
Details
(Keywords: intl)
Attachments
(13 files, 1 obsolete file)
1.44 KB,
patch
|
Details | Diff | Splinter Review | |
5.80 KB,
patch
|
Details | Diff | Splinter Review | |
5.89 KB,
patch
|
Details | Diff | Splinter Review | |
15.19 KB,
image/jpeg
|
Details | |
64.13 KB,
image/jpeg
|
Details | |
6.89 KB,
patch
|
Details | Diff | Splinter Review | |
54.27 KB,
image/jpeg
|
Details | |
6.67 KB,
patch
|
Details | Diff | Splinter Review | |
54.40 KB,
image/jpeg
|
Details | |
43.99 KB,
image/png
|
Details | |
30.84 KB,
image/jpeg
|
Details | |
2.63 KB,
patch
|
nhottanscp
:
review+
|
Details | Diff | Splinter Review |
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.
![]() |
||
Comment 1•24 years ago
|
||
ccing mpt for UI thoughts
Comment 2•24 years ago
|
||
Changing bug status to New and adding keyword intl and nsbeta1.
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 3•24 years ago
|
||
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.
Assignee | ||
Comment 4•24 years ago
|
||
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.
Assignee | ||
Comment 5•24 years ago
|
||
Assignee | ||
Comment 6•24 years ago
|
||
Reassing to waterson for the menu insersion problem.
Assignee: nhotta → waterson
Status: ASSIGNED → NEW
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
Assignee | ||
Comment 7•24 years ago
|
||
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.
Assignee | ||
Comment 8•24 years ago
|
||
Assignee | ||
Comment 9•24 years ago
|
||
Assignee | ||
Comment 10•24 years ago
|
||
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.
Updated•24 years ago
|
QA Contact: andreasb → ylong
Comment 11•24 years ago
|
||
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?
Assignee | ||
Comment 12•24 years ago
|
||
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.
Updated•24 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Comment 13•24 years ago
|
||
changing to nsbeta1-. this one does not meet beta stopper guidelines.
Updated•24 years ago
|
Target Milestone: mozilla0.9.2 → mozilla1.0
Comment 15•24 years ago
|
||
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.
Assignee | ||
Comment 16•24 years ago
|
||
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
Comment 17•24 years ago
|
||
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
Assignee | ||
Comment 18•24 years ago
|
||
Juraj, please talk to German about position of charset menu in the context menu.
Comment 19•24 years ago
|
||
Comment 20•24 years ago
|
||
Comment 21•24 years ago
|
||
Comment 22•24 years ago
|
||
Assignee | ||
Comment 23•24 years ago
|
||
"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.
Comment 24•24 years ago
|
||
Comment 25•24 years ago
|
||
Assignee | ||
Comment 26•24 years ago
|
||
r=nhotta
Comment 27•24 years ago
|
||
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
Comment 28•24 years ago
|
||
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.
Comment 29•24 years ago
|
||
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.
Comment 30•24 years ago
|
||
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.
Comment 31•24 years ago
|
||
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..."
Comment 32•24 years ago
|
||
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
Assignee | ||
Comment 33•24 years ago
|
||
Context menu to be also used controlling charset of a frame.
Ben, would that be possible by bug 26353?
Comment 34•24 years ago
|
||
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.
Comment 35•24 years ago
|
||
Comment 36•24 years ago
|
||
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.
Whiteboard: have fix, need sr → have fix, need sr | Anyone got a better testcase?
Comment 37•24 years ago
|
||
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?
Comment 38•24 years ago
|
||
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.
Comment 39•24 years ago
|
||
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.
Comment 40•24 years ago
|
||
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.
Comment 41•24 years ago
|
||
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.
Comment 42•24 years ago
|
||
Thank you for testing it.
I filed a new bug for this. It's bug 94281.
Comment 43•24 years ago
|
||
pushing out - I'll post some design suggestions/ideas this week
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Updated•23 years ago
|
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Comment 44•23 years ago
|
||
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.
Comment 45•23 years ago
|
||
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.
Comment 47•23 years ago
|
||
*** Bug 105823 has been marked as a duplicate of this bug. ***
Comment 48•23 years ago
|
||
Comment 49•23 years ago
|
||
mpt, blake - would this (attachment 54577 [details]) be acceptable for Mozilla?
Comment 50•23 years ago
|
||
I hate to be nagging - but could anyone give this UI go-ahead? I'll start the
r/sr process tomorrow.
Comment 51•23 years ago
|
||
jbetak's contract is up. Bulk move bugs to ftang
Assignee: jbetak → ftang
Status: ASSIGNED → NEW
Comment 53•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Attachment #58166 -
Flags: review+
Assignee | ||
Comment 54•23 years ago
|
||
Comment on attachment 58166 [details] [diff] [review]
updated patch - nhotta could you please try it a prehaps give it r=?
r=nhotta
Comment 55•23 years ago
|
||
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">)
Assignee | ||
Comment 56•23 years ago
|
||
MultiplexHandler(event) is added to "browserContextCharsetMenu" which is a top
level. Are there event handlers attached to other item?
Comment 57•23 years ago
|
||
thanks for looking over this alecf; would this work better?
<menu id="browserContextCharsetMenu"
oncommand="MultiplexHandler(event)"
onpopupshowing="CreateMenu 'browser');UpdateMenus(event)"/>
Comment 58•23 years ago
|
||
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 59•23 years ago
|
||
Comment 60•23 years ago
|
||
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?
Assignee | ||
Comment 61•23 years ago
|
||
Attachment #58180 -
Attachment is obsolete: true
Assignee | ||
Comment 62•23 years ago
|
||
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 63•23 years ago
|
||
Comment on attachment 58630 [details] [diff] [review]
Removed handlers from charsetOverlay.xul.
yay, this looks right.
sr=alecf
Attachment #58630 -
Flags: superreview+
Assignee | ||
Comment 64•23 years ago
|
||
Checked in.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 65•23 years ago
|
||
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.
Comment 66•23 years ago
|
||
And, both menus are not in sync, selecting one from the main menu adds an extra
selected menu item in the context menu.
Comment 67•23 years ago
|
||
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 → ---
Comment 68•23 years ago
|
||
adding dependency to bug 75338, which is tracking context menu UI.
Depends on: 75338
Comment 69•23 years ago
|
||
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.
Comment 70•23 years ago
|
||
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.
Comment 71•23 years ago
|
||
FYI: I have filed bug 112965 (RFE) for this issue.
-Neil.
Comment 72•23 years ago
|
||
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.
Comment 73•23 years ago
|
||
The top level menu item [could|should] operate on the focused frame.
Comment 74•23 years ago
|
||
*** Bug 113026 has been marked as a duplicate of this bug. ***
Comment 75•23 years ago
|
||
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
Comment 76•23 years ago
|
||
I agree with Danny. This is importand enough to be added.
Comment 77•23 years ago
|
||
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?
Comment 78•23 years ago
|
||
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.
Comment 79•23 years ago
|
||
> 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.
Comment 80•23 years ago
|
||
*** Bug 114333 has been marked as a duplicate of this bug. ***
Comment 81•23 years ago
|
||
>------- 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"
Comment 82•23 years ago
|
||
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.
Comment 83•23 years ago
|
||
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.
Comment 84•23 years ago
|
||
sorry for my misunderstanding about alecf's group.
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → ---
Comment 85•23 years ago
|
||
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
Comment 86•23 years ago
|
||
Mark as verified due we have other bugs to handle this.
Status: RESOLVED → VERIFIED
Comment 87•23 years ago
|
||
*** Bug 137480 has been marked as a duplicate of this bug. ***
Comment 88•23 years ago
|
||
*** Bug 150655 has been marked as a duplicate of this bug. ***
Comment 89•23 years ago
|
||
*** Bug 146767 has been marked as a duplicate of this bug. ***
Comment 90•22 years ago
|
||
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 → ---
Comment 91•22 years ago
|
||
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).
Comment 92•22 years ago
|
||
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.
Comment 93•22 years ago
|
||
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.
Comment 94•22 years ago
|
||
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.
Comment 95•22 years ago
|
||
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.
Comment 96•22 years ago
|
||
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).
Comment 97•22 years ago
|
||
> but given how many times intl goes around breaking things, perhaps i should?
timeless, could you elaborate on this a bit?
Comment 98•22 years ago
|
||
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.
Comment 99•22 years ago
|
||
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".
Comment 100•22 years ago
|
||
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.
Comment 101•21 years ago
|
||
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.
Comment 102•21 years ago
|
||
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
Comment 103•21 years ago
|
||
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
Comment 104•21 years ago
|
||
It is THAT hard because it's (silly) policy-related not technical.
Comment 105•21 years ago
|
||
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?
Comment 106•21 years ago
|
||
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?
Comment 107•21 years ago
|
||
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.
Comment 108•21 years ago
|
||
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.
Comment 109•21 years ago
|
||
*** Bug 237750 has been marked as a duplicate of this bug. ***
Comment 110•21 years ago
|
||
*** Bug 245329 has been marked as a duplicate of this bug. ***
Comment 111•21 years ago
|
||
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.
Comment 112•20 years ago
|
||
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
Comment 113•20 years ago
|
||
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?
Comment 114•19 years ago
|
||
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.)
Comment 115•19 years ago
|
||
This isn't still fixed in SeaMonkey because it was backed out, see comment 67.
Comment 116•19 years ago
|
||
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?
Comment 117•18 years ago
|
||
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
Comment 118•17 years ago
|
||
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.
Comment 119•17 years ago
|
||
(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.
Comment 120•17 years ago
|
||
(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)
Comment 121•17 years ago
|
||
(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.
Updated•16 years ago
|
QA Contact: amyy → i18n
Updated•15 years ago
|
Blocks: cuts-control
Comment 122•14 years ago
|
||
We've missed the 10-year anniversary for this bug! What a shame!
LOL
Comment 123•9 years ago
|
||
Telemetry shows that this feature is used extremely rarely. It is not worthwhile to polish this feature further.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 9 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•