Closed
Bug 90042
Opened 23 years ago
Closed 23 years ago
calling nsICharsetConverterManager->GetUnicodeDecoder are case sensitive
Categories
(Core :: DOM: HTML Parser, defect)
Tracking
()
VERIFIED
INVALID
People
(Reporter: gverdun, Assigned: ftang)
References
()
Details
"ISO-8859-1" works but "iso-8859-1" does not. STR: 1. go to http://www.eurosport.com 2. result: page loads: final url is: http://www.eurosport.com/home.asp? LangueID=0 3. click on "ENGLISH" 4. page does not load: final url is http://www.eurosport.com/home.asp?LangueID=2 load fails because javascript could not be converted to unicode. the charset is listed as "iso-8859-1" in step 4 and ISO-8859-1 in step 1. conversion failed in this function: nsScriptLoader::OnStreamComplete
Comment 1•23 years ago
|
||
worksforme with PC Linux 2001070806. What is the buildid and version of your Mozilla?
Updated•23 years ago
|
Assignee: harishd → bstell
Comment 2•23 years ago
|
||
-> bstell. I believe this is in an embedded windows scenario using 092.
Reporter | ||
Comment 3•23 years ago
|
||
This bug occurs in embedding. Here is a stack trace of the source of the lower case character string: nsDocument::SetDocumentCharacterSet(nsDocument * const 0x03940488, const nsAString & {...}) line 841 nsHTMLDocument::StartDocumentLoad(nsHTMLDocument * const 0x03940488, const char * 0x047e50b4, nsIChannel * 0x0365a938, nsILoadGroup * 0x03808378, nsISupports * 0x036f38c4, nsIStreamListener * * 0x0012f658, int 1) line 832 + 19 bytes nsLayoutDLF::CreateDocument(const char * 0x047e50b4, nsIChannel * 0x0365a938, nsILoadGroup * 0x03808378, nsISupports * 0x036f38c4, const nsID & {...}, nsIStreamListener * * 0x0012f658, nsIContentViewer * * 0x0012f4e0) line 392 + 45 bytes nsLayoutDLF::CreateInstance(nsLayoutDLF * const 0x03700578, const char * 0x047e50b4, nsIChannel * 0x0365a938, nsILoadGroup * 0x03808378, const char * 0x0012f60c, nsISupports * 0x036f38c4, nsISupports * 0x00000000, nsIStreamListener * * 0x0012f658, nsIContentViewer * * 0x0012f4e0) line 284 + 37 bytes nsDocShell::NewContentViewerObj(nsDocShell * const 0x036f38a0, const char * 0x0012f60c, nsIRequest * 0x0365a938, nsILoadGroup * 0x03808378, nsIStreamListener * * 0x0012f658, nsIContentViewer * * 0x0012f4e0) line 3880 + 101 bytes nsDocShell::CreateContentViewer(nsDocShell * const 0x036f38a0, const char * 0x0012f60c, nsIRequest * 0x0365a938, nsIStreamListener * * 0x0012f658) line 3777 + 60 bytes nsDSURIContentListener::DoContent(nsDSURIContentListener * const 0x03808330, const char * 0x0012f60c, int 0, nsIRequest * 0x0365a938, nsIStreamListener * * 0x0012f658, int * 0x0012f5f0) line 119 + 33 bytes nsDocumentOpenInfo::DispatchContent(nsIRequest * 0x0365a938, nsISupports * 0x00000000) line 343 + 87 bytes nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x036fc918, nsIRequest * 0x0365a938, nsISupports * 0x00000000) line 217 + 16 bytes nsHttpChannel::ProcessNormal() line 466 + 42 bytes nsHttpChannel::ProcessResponse() line 391 + 8 bytes nsHttpChannel::OnStartRequest(nsHttpChannel * const 0x0365a93c, nsIRequest * 0x03892f10, nsISupports * 0x00000000) line 2071 + 11 bytes nsOnStartRequestEvent::HandleEvent() line 109 + 53 bytes nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x03721ffc) line 64 PL_HandleEvent(PLEvent * 0x03721ffc) line 590 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x01365728) line 520 + 9 bytes _md_EventReceiverProc(HWND__ * 0x0044040a, unsigned int 49736, unsigned int 0, long 20338472) line 1071 + 9 bytes USER32! UserCallWinProc@20 + 24 bytes USER32! DispatchMessageWorker@8 + 264 bytes USER32! DispatchMessageA@4 + 11 bytes DeskTopEventProc(HINSTANCE__ * 0x00400000) line 1468 WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00142fc0, int 1) line 1002 + 9 bytes WinMainCRTStartup() line 330 + 54 bytes KERNEL32! BaseProcessStart@4 + 130958 bytes The function being called here receives the lower case version of "iso-8859-1", when it compares it to the mCharacterSet value (=="ISO-8859-1") it does not match... Perhaps this code needs to do a case insensitive compare and convert the input to upper case before assigning to mCharacterSet NS_IMETHODIMP nsDocument::SetDocumentCharacterSet(const nsAReadableString& aCharSetID) { if (!mCharacterSet.Equals(aCharSetID)) { mCharacterSet = aCharSetID; PRInt32 n = mCharSetObservers.Count(); for (PRInt32 i = 0; i < n; i++) { nsIObserver* observer = (nsIObserver*) mCharSetObservers.ElementAt(i); observer->Observe((nsIDocument*) this, NS_LITERAL_STRING("charset").get(), PromiseFlatString(aCharSetID).get()); } } return NS_OK; }
Assignee | ||
Comment 4•23 years ago
|
||
nsICharsetConverterManager->GetUnicodeDecoder is designed case sensitive. Any code which get a charset name from the net/content shoudl call nsICharsetAlias::GerPrefered before pass to nsICharsetConverterManager->GetUnicodeDecoder Make nsICharsetConverterManager->GetUnicodeDecoder case insensitive won't solve th issue since there are other charset alias for ISO-8859-1, say ISO8859-1 >This bug occurs in embedding. What does this mean? Do you mean GTKEmbed won't work bug Mozilla will ? Does the following code success ? >477 nsCOMPtr<nsICharsetAlias> calias(do_CreateInstance(kCharsetAliasCID, >478 &rv)); do you have res/charsetAlias.properties installed ?
Assignee: bstell → ftang
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 5•23 years ago
|
||
gverdun- this is an invalid bug. If you have res/charsetAlias.properties installed then you should not have this problem. We probably need to update the embedding document. You should not have this problem if you follow http://lxr.mozilla.org/seamonkey/source/embedding/config/basebrowser-win since it does include thise files there. If you folloow that file, you should not have this problem. Mark this bug as invalid.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Verified using daily build 20011004. Tried the URL on win2k, Im not seeing this problem.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•