Last Comment Bug 397309 - Hang showing certain types of content (need nsHandlerService implementation)
: Hang showing certain types of content (need nsHandlerService implementation)
Status: RESOLVED FIXED
: hang, regression
Product: Camino Graveyard
Classification: Graveyard
Component: Downloading (show other bugs)
: Trunk
: PowerPC Mac OS X
: -- blocker (vote)
: ---
Assigned To: Stuart Morgan
:
Mentors:
ftp://ftp.mozilla.org/pub/mozilla.org...
: 395768 396401 (view as bug list)
Depends on:
Blocks: 389687
  Show dependency treegraph
 
Reported: 2007-09-23 21:41 PDT by Chris Lawson (gone)
Modified: 2007-10-01 13:30 PDT (History)
9 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
zipped sample (36.98 KB, application/zip)
2007-09-23 21:49 PDT, Chris Lawson (gone)
no flags Details
fix (13.77 KB, patch)
2007-09-29 14:23 PDT, Stuart Morgan
mark: superreview+
Details | Diff | Splinter Review

Description Chris Lawson (gone) 2007-09-23 21:41:51 PDT
Trying to download a Minefield nightly to do some testing on another bug. Initiating the download hung Camino's latest trunk build every time with a similar sample to bug 397300 (though not identical).

Still need to try this with a fresh profile, but Smokey seems to think sdwilsh might know something about this being broken recently. It definitely worked in the nightly from a week ago (which was the last time I updated before tonight).
Comment 1 Chris Lawson (gone) 2007-09-23 21:49:27 PDT
Created attachment 282069 [details]
zipped sample

Yep, happens with a fresh profile too. Here's a sample (again, zipped, because the sample is a staggering 2.4 MB this time).
Comment 2 philippe (part-time) 2007-09-23 22:03:31 PDT
Strange,I usually access:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk
and have no problems downloading builds.
Comment 3 philippe (part-time) 2007-09-24 00:05:26 PDT
Would that be the same underlying issue as bug 396401 ?

A 2007090400 build has no problems downloading from the ftp:// url, but a Version 2007090601 (2.0a1pre) build hangs.
That matches the regression range noted in bug 395768 (messy thing, not fixed nor wfm actually, but the whole issue is better handled in 396401).
Comment 4 Shawn Wilsher :sdwilsh 2007-09-24 05:40:05 PDT
Hrm - I have no idea what's going on!  I'm rather curious as to what makes you think I may know what's up (might help me help you figure out what is wrong).
Comment 5 Chris Lawson (gone) 2007-09-24 07:34:04 PDT
(In reply to comment #3)
> Would that be the same underlying issue as bug 396401 ?
> 
> A 2007090400 build has no problems downloading from the ftp:// url, but a
> Version 2007090601 (2.0a1pre) build hangs.

I suppose it's possible; I probably haven't downloaded from an FTP server in at least that long. Downloads via HTTP don't seem to cause the problem.

(In reply to comment #4)
> Hrm - I have no idea what's going on!  I'm rather curious as to what makes you
> think I may know what's up (might help me help you figure out what is wrong).

Smokey mentioned on IRC that you had stopped in and apologised for breaking something related to downloads yesterday, but if this predates yesterday by a couple of weeks, I'm guessing you had nothing to do with it. Sorry for the bother, although if you have any brainstorms in the future, we'd appreciate the help :)
Comment 6 Stuart Morgan 2007-09-26 11:24:38 PDT
In debug, we get continuous spew of:
###!!! ASSERTION: Content type should be known by now.: '!mContentType.IsEmpty()', file /mozilla/netwerk/streamconv/converters/nsUnknownDecoder.cpp, line 386
###!!! ASSERTION: Content type should be known by now.: '!mContentType.IsEmpty()', file /mozilla/netwerk/streamconv/converters/nsUnknownDecoder.cpp, line 192

And the stack is recursively cycling between
nsUnknownDecoder::OnDataAvailable (nsUnknownDecoder.cpp:195)
nsDocumentOpenInfo::OnDataAvailable (nsURILoader.cpp:306)

I'll dig in more when I have time.
Comment 7 Stuart Morgan 2007-09-28 17:55:31 PDT
Taking. This is indeed due to our lack of an nsHandlerService implementation. I had more luck getting it working than I did while digging into the protocol handler bug; bundling nsHandlerService.js and a support file or two gets things working again.

It's throwing a (caught and logged, so non-fatal) exception when I download though, so I need to investigate a bit more before I make a patch.
Comment 8 Stuart Morgan 2007-09-29 08:54:37 PDT
Retitling, since the trigger is really content type, not the protocol; I've reproduced this via http as well.
Comment 9 Stuart Morgan 2007-09-29 08:55:16 PDT
*** Bug 395768 has been marked as a duplicate of this bug. ***
Comment 10 Stuart Morgan 2007-09-29 11:25:57 PDT
*** Bug 396401 has been marked as a duplicate of this bug. ***
Comment 11 Shawn Wilsher :sdwilsh 2007-09-29 12:32:52 PDT
What's the exception that you are seeing?
Comment 12 Stuart Morgan 2007-09-29 12:54:55 PDT
Well, I've made some progress unwinding the dependency chain and am past the exception that I was seeing above (I needed to add another XPT we didn't have, then set up mimeType.rdf to auto-copy to the profile), but now I get:

* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "'Component is not available' when calling method: [nsIHandlerService::getTypeFromExtension]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "<unknown>"  data: no]

I've looked at the method, but it's not clear to me what reaching the end without getting any type information indicates that I'm missing.
Comment 13 Shawn Wilsher :sdwilsh 2007-09-29 13:03:21 PDT
That's perfectly fine.  It's a bug with xpconnect (I don't know the # offhand, but myk on irc can tell you).  Native code expects the component to throw, so it's not actually getting an error.
Comment 14 Christian :Biesinger (don't email me, ping me on IRC) 2007-09-29 13:34:59 PDT
You shouldn't get a hang when you don't have a handlerservice implementation... that seems like a major bug in necko or uriloader to me.
Comment 15 Stuart Morgan 2007-09-29 14:23:56 PDT
Created attachment 282849 [details] [diff] [review]
fix

(In reply to comment #13)
> That's perfectly fine.

Glad I didn't spend any time beating against it then, thanks :)

In that case, here's the patch. It adds:
- nsHandlerService.js, and its corresponding exthandler.xpt
- XPCOMUtils.jsm, which it requires
- neck_file.xpt, so that nsHandlerService.js can use some necessary file interfaces
- mimeTypes.rdf, which needs to be shipped so that it can be copied into new profiles when needed
Comment 16 Stuart Morgan 2007-09-29 14:31:24 PDT
(In reply to comment #14)
> You shouldn't get a hang when you don't have a handlerservice implementation...
> that seems like a major bug in necko or uriloader to me.

I don't know enough about the work that's been going on in restructuring type/protocol handling to have known; I just ran into our need for nsHandlerService in our external protocol bug and had a hunch that it might be responsible for this as well when I saw the logs about content types.

Someone who is familiar with that code and knows what the expected behavior when missing nsHandlerService should probably file any core bugs that are necessary--feel free to CC me on any bugs though if more detailed debug logs or stacks from my debugging would be helpful.
Comment 17 Mark Mentovai 2007-10-01 11:09:05 PDT
Comment on attachment 282849 [details] [diff] [review]
fix

>+		0098B1230CAEA77500DA0F2F /* nsHandlerService.js in Copy Component Libraries */ = {isa = PBXBuildFile; fileRef = 0098B11D0CAEA75700DA0F2F /* nsHandlerService.js */; };
>+		0098B12A0CAEA81700DA0F2F /* nsHandlerService.js in Copy Component XPTs */ = {isa = PBXBuildFile; fileRef = 0098B11D0CAEA75700DA0F2F /* nsHandlerService.js */; };

Looks weird to put it in different phases in Camino and CaminoStatic, even though both copy to the same place.  I suggest adding a new "Copy Component Libraries" phase to CaminoStatic as in Camino, and adding this file and nsProxyAutoconfig.js to it.

>+		0098B1800CAEA9DC00DA0F2F /* XPCOMUtils.jsm in Copy Gecko Modules */ = {isa = PBXBuildFile; fileRef = 0098B17F0CAEA9CF00DA0F2F /* XPCOMUtils.jsm */; };
>+		0098B1830CAEAA0200DA0F2F /* XPCOMUtils.jsm in Copy Modules */ = {isa = PBXBuildFile; fileRef = 0098B17F0CAEA9CF00DA0F2F /* XPCOMUtils.jsm */; };

The new section should have the same name in both Camino and CaminoStatic.

>-				F5F14E9602A5A43A01A967F3 /* libwidget.rsrc */,
[...]
>+				F5F14E9602A5A43A01A967F3 /* libwidget.rsrc */,

Hmm, that's weird.  Whatever.

Looks good otherwise.  r=me with these two changes.
Comment 18 Stuart Morgan 2007-10-01 13:30:11 PDT
Landed on trunk with comments addressed (and moving the other JS library we ship (nsProxyAutoConfig.js) to the Libraries phase in both targets for consistency.

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