27646 - Need to "inherit" charset info when opening a new browser window

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P3)

Description

[[e-mail] (away - not reading bugmail)]

It doesn't work on the previous version of the Navigator, yet IE offers this 
functionality:

browse the Japanese Yahoo site, set your charset setting to Japanese (EUC), hit 
Ctrl-N to open a new browser window. Seamonkey and Navigator 4.x open the new 
window with the default charset settings. IE transfers the charset setting from 
the "parent" window - it transfers any setting, be it the charset default or 
just the currently selected charset. This might become less of an issue, once 
bug #21313 has been addressed, still I think it is a nice feature to have and 
would help with some of the view-souce issues we are still facing.

Comment 1

[Frank Tang]

jbetak- Netscape 2.0 - 4.0 does inherit the per window base charset info. This 
is a valid bug, can you work on this ? :) 

Comment 2

[[e-mail] (away - not reading bugmail)]

will do :-)

Comment 3

[leger]

Putting on the [nsbeta2-] radar. Minor inconvienence.

Comment 4

[leger]

Upating [nsbeta-] to read [nsbeta2-] in Status Whiteboard.

Comment 5

[[e-mail] (away - not reading bugmail)]

Frank, Cata,

I finally put in the changes in nsBrowserInstance.cpp, we might need to revisit
this once Cata has completed his new state object project...

Thanks everyone for your help in cracking down on this beast!

Comment 6

[Teruko Kobayashi]

I tested this in 2000-06-01-08 Win32, Mac, and Linux build.
I need to reopen this because of the following behavior.

1. Go to http://www.yahoo.co.jp/
2. Select menu View|Character coding->Multibyte->Japanese (EUC-JP)
3. Select the link and click on right button to display context menu
4. Select menu Open Link in New Window form the context menu

The Japanese characters in the new open browser page are displayed as garbage.
The charset of the page should be inherited as Japanese (EUC-JP).

Comment 7

[[e-mail] (away - not reading bugmail)]

renominating, when a new browser window is spawned, we typically miss the proper 
encoding and the user gets thrown out of context. A Japanese user browsing 
Yahoo! might click on a link and if we start a new browser instance, chances are 
that the user will be looking into a page full of "garbage" (courtesy of wrong 
encoding).

Comment 8

[leger]

Putting on [nsbeta2+] radar for beta2 fix. 

Comment 9

[Scott MacGregor]

Unfortunately the JS changes for this bug that were introduced to
tasksOverlay.js have some serious side effects and break URI dispatching. The
changes cause us to create an extra browser instance when you try to create a
new navigator window. It then sets this new browser instance as the parent for
original window. So now you have mail, compose and aim windows who think there
parent is this bogus browser instance. This breaks URI dispatching when we try
to figure if a given window can handle certain content types because we now
think the window is a browser window.

This was the cause of Bug #40164 among others.

It looks like you want to just pass the charset of the document in the original
navigator as the charset to be used for the new navigator window you are trying
to create. Instead of doing all that work creating this bogus browser instance,
I think you can do this in just one line of JS:

window.content.document.characterset.
This gives you the charset of the current document in the current window.

I'm attaching a patch for your consideration which just uses this instead of
creating the extra browser instance that caused so much trouble.

This seemed to be working for me in fixing both this bug and the regression in
40164.

The only thing you might want to do is make sure the window type is of type
browser.navigator before extracting the charset of the document. It probably
doesn't make sense to do it if the originating window was a mail or a compose
window.

Comment 10

[Scott MacGregor]

Attachment: A proposed fix for this and the regression this bug caused (40164)

Comment 11

[Scott MacGregor]

I modified this proposed fix slightly. Instead of always trying to get a charset
from the document, I added an extra check to make sure the originating window
was a browser window and only passing in the charset if both the original window
and the desired new window we are creating have a window.windowtype value equal
to "navigator.browser"

jbetak has reviewed this so I'll check it in.

I'll take the liberty of marking this bug fixed. The problem in this bug seems
to be working okay for me with this patch.

Comment 12

[Teruko Kobayashi]

I tested this in 2000-06-19-08 Win32, Mac, and Linux build.
This still does not work correctly.

1. Go to http://www.yahoo.co.jp/
2. Select menu View|Character coding->Multibyte->Japanese (EUC-JP)
3. Select the link and click on right button to display context menu
4. Select menu Open Link in New Window form the context menu

The Japanese characters in the new open browser page are displayed as garbage.
The charset of the page should be inherited as Japanese (EUC-JP).

Comment 13

[Scott MacGregor]

That's probably because open link in new window through the context window
doesn't go through tasksOverlays.js. That's the only spot where the code was
modified to inherit the charset of the owning window (if that window is a
browser window).

A similar change problably needs made in the js for the browser context menu.

Comment 14

[Mike]

M16 has been out for a while now, these bugs target milestones need to be 
updated.

Comment 15

[Frank Tang]

I just try the File;New Window, it does not work neither. I find that 
window.windowtype is "undefined" in the tasksOverlay.js

Comment 16

[Scott MacGregor]

Hmm, frank, the window.windowtype JS syntax must have broken. Add this code
instead and you'll be back in business again:

var wintype = document.firstChild.getAttribute('windowtype');
then use wintype in place of the window.windowtype useage I was using before.


That should re-fix this bug.

Comment 17

[Frank Tang]

mscott- thanks, I will try.

Comment 18

[Frank Tang]

nhotta- please fix. Thanks

Comment 19

[Teruko Kobayashi]

When I tested this in Naoki's local build, we found the other problem.

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.

   Inherit character coding does not work in <a href= xxxx target="new">.

Naoki fixed the problem in Open Link in New Window form the context menu.

Comment 20

[nhottanscp]

Attachment: js patch, not include a fix for the newly discovered problem

Comment 21

[nhottanscp]

Teruko, please file a separate bug for target="new" problem. The problem is in a 
different place (not in JS code).

Comment 22

[nhottanscp]

I checked in fixes for the new window problem and a context menu problem.
Please file a separate bug for the remaining problem.

Comment 23

[Teruko Kobayashi]

I verified this in 2000-07-12-08 Win32, 2000-07-10-20 Mac, and 2000-07-12-11 
Linux build.