Closed Bug 98395 Opened 20 years ago Closed 6 years ago

Need the separate character coding menu in the different frame

Categories

(Core :: Internationalization, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX
mozilla1.2alpha

People

(Reporter: teruko, Assigned: smontagu)

References

(Blocks 1 open bug, )

Details

(Keywords: intl, Whiteboard: [need info])

Attachments

(1 file, 6 obsolete files)

Right now, we can change character coding menu from View menu only.
If the different frame is the different character coding, we cannot change
character coding
menu for each frame.  

Steps of reproduce
1. Go to above URL
   Both frame does not have meta charset info. Left frame page is written as
Euc-JP and 
   right frame page is written as Shift_JIS.
2. Select menu View | Character coding->More->East Asian->Japanese (EUC-JP)
   Only Japanese characters in the left frame page are displayed correctly.

It is nice to handle charset in the different frames.  

Tested 9-05 trunk build.
Keywords: intl
QA Contact: andreasb → teruko
assigning to ftang for feature implementation.
Assignee: yokoyama → ftang
reassign this to shanjian
shanjian, please consider this as m96-m97 feature.
we could use the following way to solve this issue
1. display focus frame and let the charset menu frame sensitive. Similar to what 
we did for print frame in 4.x
2. use contextual menu. 
shanjian
Assignee: ftang → shanjian
accepting.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
Keywords: mozilla1.0
Nominating this as nsbeta1.
Keywords: nsbeta1
nsbeta1+ per i18n triage
Keywords: nsbeta1nsbeta1+
I have a partial fix on my tree. I have been told that naoki has a working
patch. Give it to naoki.
Assignee: shanjian → nhotta
Status: ASSIGNED → NEW
Shanjian, what kind of changes have you done?
All we have now is the .js & .xul to hook up to the context menu, no frame support.
If you work on the backend change to enabling frame base charset change, please
continue working on that. You can reassign back to me if that's not the case.
Assignee: nhotta → shanjian
nsbeta1- because no customer ask for it and it is a *new* feature
please talk to roy and hansoo about this.
Keywords: nsbeta1+nsbeta1-
Blocks: 63054
There are several bugs related to frames and charset encodings and
they have been morphing into things which are not always the same
as the current Summary.

Has this bug morphed into the need for a "backend change to enabling
frame base charset change"?

If so, there are customers who want to be able to change charset encoding
for a given frame.

Comments:
Bug 26353 http://bugzilla.mozilla.org/show_bug.cgi?id=26353#c28

  ...I believe, make a lot of Mozilla users (who need to
  view non-US-ASCII pages very often among other things) a lot happier
  :-) or prevent them from turning to MS IE (I have to resort to MS IE
  frequently because I can't change the encoding, print the page, take
  the URL,  etc in a chromless window) Therefore, I thought it might not
  be so bad to spur a little more activities here by writing this comment.

There are several comments with examples of cases where this is needed
in bug 63054:
  http://bugzilla.mozilla.org/show_bug.cgi?id=63054#c18
  http://bugzilla.mozilla.org/show_bug.cgi?id=63054#c19
  http://bugzilla.mozilla.org/show_bug.cgi?id=63054#c39
  http://bugzilla.mozilla.org/show_bug.cgi?id=63054#c41

In bug 70830, http://bugzilla.mozilla.org/show_bug.cgi?id=70830#c83
  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!
Status: NEW → ASSIGNED
push to 1.01
Target Milestone: mozilla1.0 → mozilla1.0.1
*** Bug 155509 has been marked as a duplicate of this bug. ***
*** Bug 155858 has been marked as a duplicate of this bug. ***
Blocks: 157673
nsbeta1+ for m1.2final release. 
Keywords: nsbeta1-nsbeta1+
Target Milestone: mozilla1.0.1 → mozilla1.2alpha
shanjian:
please add context charset menu too when browsing non-frame homepages,
then you can fix many other bugs like 70830...
This patch add Charset Encoding menu in right click context menu.
The menu is frame-sensitive.

The Charset Encoding menu may be useful in a javascript opened window without
menu on it, see the description in bug 155858.
This patch add Charset Encoding menu in right click context menu.
The menu is frame-sensitive.

The Charset Encoding menu may be useful in a javascript opened window without
menu on it, see the description in bug 155858.
Attachment #95991 - Attachment is obsolete: true
Attachment #95992 - Attachment is obsolete: true
Attachment #95993 - Attachment is obsolete: true
Simford, I updated your patch to include charset detector and customize charset
menu item. The handler is also changed to the one used by browser menu.
Blaker, could you review the code?
shanjian:

I have tried your new patch. It works well but still has a little mess:
the menu state can not be synchronized between context menu and View menu.
i.e. when you choose a Charset (say A) in context menu, the homepage reloads, 
the context menu shows that A is current charset, 
but View/Character Encoding still shows the old one (say B).
They are async.

However, when you choose the charset encoding from the View/Character Encoding,
the context menu will synchronize with it!

very strange, huh.
After many tries, I find that it depends on the sequence you use Charset
Encoding menu.

the 1st test:
1. After lanch Mozilla, 
2. open a homepage, 
3. change charset encoding with context menu,
4. change charset encoding with View/Character Encoding

then context menu state can be sync with View/Character Encoding menu,
but viceversa, no.

2nd test:
1, 2, 4, 3

then View menu can be sync with context menu, but no viceversa.

Maybe we should use different menu objects instead of pointing to the same one.
Thanks for trying it out. I will look into this. 
both the charset menu in browser and charset menu in context, they are generated
by the same menu id. So whoever is created first, it will be referenced by
"getElementId()". I could not find a solution to this problem yet. 

An alternative solution is to disable the context charset menu when main menu is
available. 
The context menu for non-frame part is moved to bug 70830. This bug will soly
handle frame charset issue. 
Attachment #97794 - Attachment is obsolete: true
Attachment #94505 - Attachment is obsolete: true
Attachment #95994 - Attachment is obsolete: true
cc ben and mpt. Please speakup if you have disagreement again this ui change. 
err. there has to be a better way to do this.

suppose i end up with a dom something like this:
<frameset id=a>
 <frame id=b>
 <frameset id=c>
  <frame id=d>
  <frame id=e>
  <frame id=f>
   <iframe id=g>
  </frame>
 </frameset>
</frameset>
would it be reasonable for me to want to change the character coding of frames
D, E and F together?

If there was a way to select C and then select a character coding (using the
menubar) then I could do that.

If I wanted to change the character coding for all of the frames, then if i
could select A, then I could use the menubar to select a character coding.

This requires three things:
1. being able to select any frameset/frame/iframe. 
2. being able to show the menubar (macos has no problem, we can rely on <alt> to
show it, or a context menuitem to show it)
3. selecting a character coding from the menubar should affect the selected
frame(set) and all children.

AaronL: how unreasonable is 1?
DanM: i know you're already sick of this and it's new bugs to you, but how
unreasonable is 2?
> would it be reasonable for me to want to change the 
> character coding of frames D, E and F together?

It is my understanding that any encoding change should
propagate to all the children nodes but not to a parent
node. That is how I have understood the spec we have out
on Mozilla.org for the past 3 years or so.
So what you want would have to occur per spec.
cc samir
Comment on attachment 100912 [details] [diff] [review]
latest patch that only address frame charset encoding.

the same charset update problem seems exist in frame context menu as well, need
more investigation.
Attachment #100912 - Flags: needs-work+
is that possible you can make a screen shot about the work?
I won't mind (neither support) if we do not include those "more charset"
submenus if people really feel bad about those ...
ftang, I found a charset update problem which I could not find a solution yet.
Before that is solved, I can't move on.
i18n triage team: need info on user base affected.
Keywords: nsbeta1+nsbeta1
Whiteboard: [need info]
*** Bug 195341 has been marked as a duplicate of this bug. ***
per i18n triage meeting: nsbeta1-
Keywords: nsbeta1nsbeta1-
Blocks: 254868
shanjian is no longer working on mozilla for 2 years and these bugs are still
here. Mark them won't fix. If you want to reopen it, find a good owner first. 
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Mass Re-assinging Frank Tangs old bugs that he closed won't fix and had to be
re-open. Spam is his fault not my own
Assignee: shanjian → nobody
Status: REOPENED → NEW
Filter on "Nobody_NScomTLD_20080620"
Assignee: nobody → smontagu
QA Contact: teruko → i18n
Telemetry shows that this feature is used extremely rarely. It is not worthwhile  polish this further.
Status: NEW → RESOLVED
Closed: 17 years ago6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.