Created attachment 171369 [details] How Firefox displays iframe contents that has been dynamically created.
Your test page given at the URL is NOT in ISO-8859-2 but mixes two character encodings, ISO-8859-2 and Windows-1250 in a single HTML file. 'ś' (this is in UTF-8. please, use UTF-8 whenever you add a comment with non-ASCII content by setting View | Character encoding to UTF-8 BEFORE writing your comment) in ISO-8859-2 is 0xB6 while it's 0x9C. Note that '0x9C' is invalid (or represents a C1 control character) in ISO-8859-2 so that it's rendered as '?' As for 'iframe'... this is an interesting case.. I'm not sure which component this belongs to...
I meant to change the product to Core
What's going on here is: 'ś' (0xB6) in ISO-8859-2 is translated into UTF-16 (0x01 0x5B) and then emitted as '0x5B' by trucating high-byte (UTF16 -> ASCII conversion). The same happens to 0x9C which is translated into 0xFF 0xFD (U+0FFFD : Not a character) because 0x9C in ISO-8859-2 is invalid. When emitted, it turns to 0xFD (0xFF is truncated by lossy UTF16 -> ASCII conversion) which is 'ý' in ISO-8859-2 (as well as in ISO-8859-1) I don't think MS IE honors charset in 'meta tag' (of a dynamically created iframe) but it just emit 'DOM content' in the charset of the parent document.
See the XXX comment at http://lxr.mozilla.org/seamonkey/source/dom/src/jsurl/nsJSProtocolHandler.cpp#264 -- that's what's causing this bug. The idea of having a real UTF-data stream has come up before. See what nsDOMParser does, eg, in ConvertWStringToStream. The JS url code should probably do something similar, or we should factor the code out into a NS_NewUTF8InputStream method or something.
Fixed by bug 335298 *** This bug has been marked as a duplicate of 335298 ***