This bug is separated from the bug 27646. Inherit character coding does not work in <a href= xxxx target="new"> 1. go to http://news.yahoo.co.jp/Full_Coverage/Aum/ 2. select menu View|Character coding->Multibyte->Japanese (EUC-JP) 3. click on the link under "関連ニュース" The Japanese characters in the new page are not displayed correctly. Tested 2000-07-11-08 build.

Reassing to ftang.

shanjian- please help

nsbeta3+ per i18n bug meeting.

shanjian, are you working on this bug ? I think this one is more important than the remaining IME bug.

P4

what is the progress? can you put the comment here?

shanjian said he have no good progress on this. We should consider drop this.

cut this out from nsbeta3 list since 1. auto-detect reduce the chance that we hit this. 2. user coudl still select the character coding menu to select the right one.

Added nsbeta1 and intl keywords.

Changed QA contact to ylong@netscape.com.

The url http://news.yahoo.co.jp/Full_Coverage/Aum/ has been redirected to another one: http://dailynews.yahoo.co.jp/fc/ which doesn't has the "関連ニュース" there.

I created test case in http://babel/tests/browser/html/euc-jp/new-target.html. When you click "クリック", the Japanese characters in new page are not displayed correctly.

move to moz0.9.3

This is not a easy bug. Mark it 1.0, but hope I can fix it sooner.

explaination to the patch: In navigator.js, function Startup() AND OpenBrowserWindow() in taskOverlay.js, the same thing is done through js. So we want to do the same thing to open link in new target through link click.

rick, could you review my fix? thanks.

hi shanjian, the patch looks good. however, i'd put the code in nsDocShell::FindTarget(...) rather than nsDocShell::InternalLoad(...). FindTarget(...) actually creates the new window, so i think it would be cleaner to inherit the character coding there... r=rpotts -- rick

add waterson to cc list. Chris, can you sr this one? thanks!

Couple nits: 1. use nsXPIDLString for |defaultCharset| instead of raw PRUnichar pointer and |Recycle()|. 2. fix goofy tabs 3. Declaration of |defaultCharset| ought to be _inside_ the |if (muCV && target_muCV) {|, right? Fix those, and sr=waterson

chris, I update my patch as you suggested. By the way, is there any documentation about those string class we are using in mozilla? It is constantly changing and there are multiple practice in the code base, it confused me a lot when dealing with string in mozilla.

looks good to me... r=rpotts

a=tor on behalf of drivers

fix checked in.

Fixed verified on 09-04 trunk build on Win2k-CN and Linux RH6.2-Ja.