Last Comment Bug 226262 - New windows opened via javascript should inherit main windows character encoding
: New windows opened via javascript should inherit main windows character encoding
Status: NEW
: regression
Product: Core
Classification: Components
Component: Internationalization (show other bugs)
: Trunk
: x86 All
: -- normal with 2 votes (vote)
: ---
Assigned To: Simon Montagu :smontagu
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-19 14:41 PST by rjf
Modified: 2009-08-23 09:05 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase from bug 70507 comment 0 (502 bytes, text/html)
2003-11-19 15:08 PST, Simon Montagu :smontagu
no flags Details

Description rjf 2003-11-19 14:41:50 PST
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
UTF-8.

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 Simon Montagu :smontagu 2003-11-19 15:03:47 PST
Confirming. This is apparently a regression of bug 70507.
Comment 2 Simon Montagu :smontagu 2003-11-19 15:08:24 PST
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 rjf 2003-11-19 15:18:27 PST
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.

Thanks!
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2003-11-19 17:56:52 PST
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....

Note You need to log in before you can comment on or make changes to this bug.