calling nsICharsetConverterManager->GetUnicodeDecoder are case sensitive

VERIFIED INVALID

Status

()

Core
HTML: Parser
--
critical
VERIFIED INVALID
17 years ago
17 years ago

People

(Reporter: Gustavo Verdun, Assigned: Frank Tang)

Tracking

Trunk
All
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

17 years ago
"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

17 years ago
worksforme with PC Linux 2001070806.

What is the buildid and version of your Mozilla?

Updated

17 years ago
Assignee: harishd → bstell

Comment 2

17 years ago
-> bstell. I believe this is in an embedded windows scenario using 092.
(Reporter)

Comment 3

17 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

17 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

17 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
Last Resolved: 17 years ago
Resolution: --- → INVALID

Updated

17 years ago
QA Contact: bsharma → moied

Comment 6

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