122772 - Mozilla hangs when visiting URL

Status: VERIFIED FIXED

(Core Graveyard :: File Handling, defect)

Description

[Karl Johan Kleist]

Build ID: 2002 01 30 03. Windows 2000.

Visiting < http://www.agfamonotype.co.uk/survey/freemac.hqx > causes Mozilla to
hang.

Notice that these to sibling links work fine - causing the
"Downloading... " dialog to be opened:

< http://www.agfamonotype.co.uk/survey/freepcps.zip >

< http://www.agfamonotype.co.uk/survey/freepctt.zip >

Comment 1

[Ashley Bischoff (blog at handcoding.com)]

Confirming 2002013003 on Win2k and marking NEW.

-> File Handling, but punt as needed

Comment 2

[WD]

Confirming hang.  Moz uses 100% CPU and is unresponsive.
2002013003 (0.9.8 branch)

Comment 3

[Bill Law]

WFM

Can somebody seeing the hang tell me if you've got a helper app entry for .hqx
files (or for the content type application/x-stuffit)?

Comment 4

[Ashley Bischoff (blog at handcoding.com)]

Bill: I have no helper applications defined for that. Also, which Build ID and
OS are you using for WFM?

Comment 5

[WD]

No helper app for HQX here.
I do have Winzip installed on my system, which is associated with HQX files
though.   But I have in no way set up mozilla to automatically launch Winzip in
such a case.

Comment 6

[Bill Law]

2002012903 build, Win2K

Can you try creating a helper app entry for that mime type and see what happens
(just say open it with notepad or something).  Have you tried waiting a long
time to see if Mozilla will eventually display it as plain text?  I've seen that
happen when there's confusion about the content type.

Comment 7

[Ashley Bischoff (blog at handcoding.com)]

Bill: Your BuildID is key -- this bug doesn't appear until 20020130 or later
(AFAIK).

Comment 8

[Bill Law]

Attachment: Patch

This makes the problem go away.  I'm concerned about the fact that this code
hasn't changed in the recent past and the problem is maybe triggered by a more
recent change in the string code.  That change might bite us later if we don't
find the other victims or remedy this problem.

Note that the code changed here said "PR_TRUE" but I think it really meant "1".
 It isn't obvious what FindChar is supposed to do when asked to start beyond
the end of the string.

I'm going to reassign this to jag so he can assess the string library issues. 
Jag, if this is just due to something on this end, just reassign it back to me.

Comment 9

[Bill Law]

->jag to answer why this seems to have recently broke and to verify that it is
the caller's problem

Comment 10

[jag (Peter Annema)]

Comment on attachment 67329 [details] [diff] [review]
Patch

sr=jag

Comment 11

[Alec Flett]

Comment on attachment 67329 [details] [diff] [review]
Patch

argh! I don't know how I missed these. There are too many
FindChar()'s...r=alecf

Comment 12

[Alec Flett]

oh wait!
some of those are nsString, and some are nsCString

Argh..but in every case the use of PR_TRUE/PR_FALSE was unnecessary. maybe we
ought to fix nsCString too...

Comment 13

[jag (Peter Annema)]

-> alecf

Alec, when you've checked in your patch for 107575 you should be able to close
this as fixed.

Comment 14

[Alec Flett]

ok the ultra mega patch from bug 107575 has landed, which includes this.

Comment 15

[sairuh (rarely reading bugmail)]

no longer get a hang when visiting the test url. vrfy'd with 2002.02.04.11 comm
bits on win2k.