Composer charset does not inherit from Browser charset

VERIFIED FIXED in mozilla1.0

Status

()

Core
Internationalization
P3
major
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: Teruko Kobayashi, Assigned: jbetak@netscape.com (away - not reading bugmail))

Tracking

({intl})

Trunk
mozilla1.0
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

18 years ago
When you browse the page which does not have meta tag and set the charset coding 
in browser and try to edit the page in Composer, the character coding is not
same as Browser.

Steps of reproduce
1. Open Navigator
2. Go to http://www.yahoo.co.jp/
3. Select menu View|Character coding->Japanese(EUC-JP)
4. Select menu File|Edit page 

In the Composer, the Japanese characters are not displayed correctly.
Japanese (EUC-JP) should be set in Composer.

Tested 2000-07-12 build.

Comment 1

18 years ago
Reassign to ftang.
Assignee: nhotta → ftang

Updated

18 years ago
Status: NEW → ASSIGNED

Updated

18 years ago
Keywords: nsbeta3

Comment 2

18 years ago
nsbeta3- per i18n bug meeting.
Thsi may be fixed partially by 21313. Teruko should check 4.x behavior.
Even we don't fix it, we don't think user will hit this .
Whiteboard: [nsbeta3-]
(Reporter)

Comment 3

18 years ago
This works fine in 4.x.  Composer remembers the charaset in browser.
(Reporter)

Comment 4

17 years ago
Added intl and nsbeta1 keywords.
Keywords: intl, nsbeta1
(Reporter)

Comment 5

17 years ago
Changed QA contact to ylong@netscape.com.
QA Contact: teruko → ylong

Updated

17 years ago
Summary: Composer charset does not inherite from Browser charset → Composer charset does not inherit from Browser charset

Comment 6

17 years ago
composer bug.
mark this as moz0.9 and reassign to yokoyama.
Assignee: ftang → yokoyama
Status: ASSIGNED → NEW
Keywords: nsbeta3
Whiteboard: [nsbeta3-]
Target Milestone: --- → mozilla0.9

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9 → ---

Comment 7

17 years ago
Roy/Ftang - Can we get this fixed for M0.9.1
Target Milestone: --- → mozilla0.9.1

Comment 8

17 years ago
www.yahoo.co.jp works now (yahoo added server charset).  
Use www.kinokuniya.co.jp to reproduce the bug. 

Comment 9

17 years ago
I guess this bug has 2 issues:
1. Page can not display correctly
2. Correct Charset in Browser has not been set in Composer.

So for Yahoo-Japan, there is charset in their server, when you bring
this page to Composer, the page will display correctly, however, there
is no correct charset has been marked in Composer so that when you 
save the page to a file and re-open it, it won't display correctly.
And for www.kinukuniya.co.jp - it doesn't display correctly and 
charset was not marked to shift-jis neither.

Comment 10

17 years ago
Yuying Long : I don't think we have two issues here.  Only one!!
You issue #1 is correct behaviour when you have 
the Auto-detect OFF (by default).  I see www.kinukuniya.co.jp gets
displayed correctly when you have the Auto-Detect ON. 

Comment 11

17 years ago
teruko:  Is this duplicate of 45408? 

Comment 12

17 years ago
Teruko: sorry I meant 77229.
(Reporter)

Comment 13

17 years ago
Changed URL.
(Reporter)

Comment 14

17 years ago
*** Bug 77229 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 15

17 years ago
I mark 77229 as dup of this bug since this is found earlier.

Comment 16

17 years ago
Please have a look. Thanks
Assignee: yokoyama → jbetak
Status: ASSIGNED → NEW
I've looked into the JS window handlers a week ago in my local build and they
appeared to extract and pass the document charset into new browser instances
correctly. 

I recall a time, when the JS handlers got broken by some other changes in the
product, but that seems no longer to be the case. I just spoke to Yuying about
some related issues, which should be addressed for 0.9.1.

I just re-tested with the 0.9 Mozilla release and it seems to work there...
Please make sure that you clear your disk and memory cache
(Preferences->Advanced->Cache) and remove any bookmarks referring to the page,
when testing this. Mozilla pulls the charset info from many sources, cache and
bookmarks are among them, which might not be immediately transparent.

Status: NEW → ASSIGNED
teruko,

could you please see, whether this works for you in the latest build? I think
the problem went away. 

I just checked a few things in my private build and I might want to put in a
little modification, but if it works for you now I might bump this bug to 1.0.
(Reporter)

Comment 19

17 years ago
I tested this in 2001050804 Win32 build.  This works fine.  I found the 
problem if the page has meta charset. - bug 79735
moving to 1.0
Target Milestone: mozilla0.9.1 → mozilla1.0

Comment 21

17 years ago
0508 Win32 trunk build on Win2k-CN:
1. For he original report page: http://www.yahoo.co.jp/, it will display fine in 
Composer when you select EUC-JP in browser first, however, the problem is 
charset EUC-JP has not been marked in Composer when View | Character Coding.
2. For the page that changed in URL field: 
http://babel/tests/editor/charsetmenu/Selected_data_west_sjis.htm
I was not seeing it display correctly in Composer, the charset Shift-JIS has not 
been marked as well.
Yuying,

it appears that 
http://babel/tests/editor/charsetmenu/Selected_data_west_sjis.htm
is also mislabeled as Latin-1. Teruko open a new bug for handling of mislabeled 
pages in composer - bug 79735.

The checkmark drawing problem will take some time to fix, since we are waiting 
on Waterson (bug 78290) and there is another problem with the composer menu - 
bug 39780, where the new entries don't get added to the menu and subsequently 
can't get check marked.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
I believe this works now as expected. Since we have a new bug (bug 79735) for 
the changes I wanted to make to the composer charset handling, I'll go ahead 
and close this.

Comment 24

17 years ago
I'll mark it as verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.