397309 - Hang showing certain types of content (need nsHandlerService implementation)

Status: RESOLVED FIXED

(Camino Graveyard :: Downloading, defect)

Description

[Chris Lawson (gone)]

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)]

Attachment: 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)]

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)]

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]

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)]

(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]

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]

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]

Retitling, since the trigger is really content type, not the protocol; I've reproduced this via http as well.

Comment 11

[Shawn Wilsher :sdwilsh]

What's the exception that you are seeing?

Comment 12

[Stuart Morgan]

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]

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)]

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]

Attachment: 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]

(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]

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]

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.