User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Our application opens new windows and displays dynamic content within those
windows. Currently there does not appear to be a way to set the encoding of the
new window, and it does not inherit the main windows encoding.
If the content in the new window were coming from the server, then the encoding
would get set correctly via the http header. Instead, when a window is created
it gets an encoding compatible with (or identical to) the current OS encoding,
instead of the encoding set in the parent browser window.
For example, our browser window is in UTF-8, yet new windows opened via
to UTF-8 in this specific case. This is the behavior of "the other" browser, and
makes sense given that one cannot always rely on going back to the server to
generate the content for the new window.
Steps to Reproduce:
1. Load a document into the main browser with encoding set to UTF-8.
2. From that document, open a new window and examine the character set encoding
for that window.
The character set encoding will likely be us-ascii, or some encoding other than
Set the initial character set encoding for the new window to that of the parent
window, or UTF-8 in this case.
Confirming. This is apparently a regression of bug 70507.
Created attachment 135955 [details]
Testcase from bug 70507 comment 0
Note that the window that comes up displays the Japanese correctly, but it is
NOT in the correct character set.
This can be verified by going to the character set pulldown.
Simon, excellent, thanks for the test case.
Note, that if you were to post the data from the new window, it would use
whatever encoding the new window is in, and that is really where the issue shows
up, as the data will almost certainly get munged on the way to the server, based
on the incorrect encoding.
For some reason the docshell of the newly-opened document has a null content
viewer when nsHTMLDocument::StartDocumentLoad is called. Therefore the charset
can't be gotten off the content viewer....