The default bug view has changed. See this FAQ.

Hang showing certain types of content (need nsHandlerService implementation)

RESOLVED FIXED

Status

Camino Graveyard
Downloading
--
blocker
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: Chris Lawson (gone), Assigned: Stuart Morgan)

Tracking

({hang, regression})

Trunk
PowerPC
Mac OS X
hang, regression

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
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).
(Reporter)

Comment 1

10 years ago
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

10 years ago
Strange,I usually access:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk
and have no problems downloading builds.

Comment 3

10 years ago
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).
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).
(Reporter)

Comment 5

10 years ago
(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 :)
Summary: Downloading causes browser to hang → Downloading via ftp:// URI causes browser to hang
(Assignee)

Comment 6

10 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 7

10 years ago
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.
Assignee: nobody → stuart.morgan
(Assignee)

Comment 8

10 years ago
Retitling, since the trigger is really content type, not the protocol; I've reproduced this via http as well.
Summary: Downloading via ftp:// URI causes browser to hang → Hang showing certain types of content (need nsServiceHandler implementation)
(Assignee)

Updated

10 years ago
Duplicate of this bug: 395768
(Assignee)

Updated

10 years ago
Duplicate of this bug: 396401
What's the exception that you are seeing?
(Assignee)

Comment 12

10 years ago
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.
(Assignee)

Updated

10 years ago
Blocks: 389687
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.
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.
(Assignee)

Comment 15

10 years ago
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
Attachment #282849 - Flags: superreview?(mark)
(Assignee)

Comment 16

10 years ago
(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.
Summary: Hang showing certain types of content (need nsServiceHandler implementation) → Hang showing certain types of content (need nsHandlerService implementation)

Comment 17

10 years ago
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.
Attachment #282849 - Flags: superreview?(mark) → superreview+
(Assignee)

Comment 18

10 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.