98395 - Need the separate character coding menu in the different frame

Status: RESOLVED WONTFIX

(Core :: Internationalization, enhancement)

Description

[Teruko Kobayashi]

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.

Comment 1

[Roy Yokoyama]

assigning to ftang for feature implementation.

Comment 2

[Frank Tang]

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. 

Comment 3

[Frank Tang]

shanjian

Comment 4

[Shanjian Li]

accepting.

Comment 5

[Teruko Kobayashi]

Nominating this as nsbeta1.

Comment 6

[nhottanscp]

nsbeta1+ per i18n triage

Comment 7

[Shanjian Li]

I have a partial fix on my tree. I have been told that naoki has a working
patch. Give it to naoki.

Comment 8

[nhottanscp]

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.

Comment 9

[Frank Tang]

nsbeta1- because no customer ask for it and it is a *new* feature
please talk to roy and hansoo about this.

Comment 10

[bobj]

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!

Comment 11

[Shanjian Li]

push to 1.01

Comment 12

[Matthias Versen [:Matti]]

*** Bug 155509 has been marked as a duplicate of this bug. ***

Comment 13

[Alfonso Martinez]

*** Bug 155858 has been marked as a duplicate of this bug. ***

Comment 14

[Frank Tang]

nsbeta1+ for m1.2final release. 

Comment 15

[Shanjian Li]

Attachment: patch (charset reload via frame context menu)

Comment 16

[Simford]

shanjian:
please add context charset menu too when browsing non-frame homepages,
then you can fix many other bugs like 70830...

Comment 17

[Simford]

Attachment: complete "Charset Encofing" in right click menu

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.

Comment 18

[Simford]

Attachment: complete "Charset Encofing" in right click menu

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.

Comment 19

[Shanjian Li]

Attachment: patch (frame context charset + non-frame context charset)

Comment 20

[Shanjian Li]

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.

Comment 21

[Shanjian Li]

Blaker, could you review the code?

Comment 22

[Simford]

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.

Comment 23

[Simford]

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.

Comment 24

[Shanjian Li]

Thanks for trying it out. I will look into this. 

Comment 25

[Shanjian Li]

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. 

Comment 26

[Shanjian Li]

The context menu for non-frame part is moved to bug 70830. This bug will soly
handle frame charset issue. 

Comment 27

[Shanjian Li]

Attachment: latest patch that only address frame charset encoding.

Comment 28

[Shanjian Li]

cc ben and mpt. Please speakup if you have disagreement again this ui change. 

Comment 29

[timeless]

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?

Comment 30

[Katsuhiko Momoi]

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

Comment 31

[Shanjian Li]

cc samir

Comment 32

[Shanjian Li]

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.

Comment 33

[Frank Tang]

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

Comment 34

[Shanjian Li]

ftang, I found a charset update problem which I could not find a solution yet.
Before that is solved, I can't move on.

Comment 35

[Samir Gehani]

i18n triage team: need info on user base affected.

Comment 36

[R.K.Aa.]

*** Bug 195341 has been marked as a duplicate of this bug. ***

Comment 37

[marina]

per i18n triage meeting: nsbeta1-

Comment 38

[Frank Tang]

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. 

Comment 39

[Travis Chase]

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

Comment 40

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 41

[Henri Sivonen (:hsivonen)]

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