New windows opened via javascript should inherit main windows character encoding

Assigned to



15 years ago
9 years ago


(Reporter: fb, Assigned: smontagu)




Firefox Tracking Flags

(Not tracked)



(1 attachment)



15 years ago
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
javascript have an encoding of "us-ascii". The new window should instead default
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.

Reproducible: Always

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.
Actual Results:  
The character set encoding will likely be us-ascii, or some encoding other than

Expected Results:  
Set the initial character set encoding for the new window to that of the parent
window, or UTF-8 in this case.

Comment 1

15 years ago
Confirming. This is apparently a regression of bug 70507.
Ever confirmed: true


15 years ago
Keywords: regression

Comment 2

15 years ago
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.

Comment 3

15 years ago
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....
QA Contact: amyy → i18n
You need to log in before you can comment on or make changes to this bug.