BUILD: linux 2001-04-02-16 STEPS TO REPRODUCE: 1) go to above URL ACTUAL RESULTS: A helper app dialog box pops up for the application/vnd.mozilla.xul+xml mimetype EXPECTED RESULTS: A helper app dialog box for the text/xul mimetype NOTES: The problem lies in http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperAppService.cpp#216 -- the implementation of nsExternalHelperAppService::DoContent We try to guess a content type when the one returned by the server is unknown. If the guessed type is an internal type that is not handled by any helper apps (eg application/vnd.mozilla.xul+xml or text/html) then we end up putting up a "pick an application or save" dialog for that bogus mimetype. This is very confusing to users.

*** Bug 73736 has been marked as a duplicate of this bug. ***

*** Bug 74544 has been marked as a duplicate of this bug. ***

this isn't an xpapps bug -- the problem is in uriloader...

ccing mscott, who wrote the original code.

could this be a dup of [or, related to] bug 46655?

Possibly related, if not from the same cause. I tried tracing through the code, but got lost along the way. I noticed that xpfe/components/ucth isn't used, and http://lxr.mozilla.org/seamonkey/source/uriloader/base/nsURILoader.cpp#334 contains: 334 // BIG TIME HACK ALERT!!!!! WE NEED THIS HACK IN PLACE UNTIL OUR NEW UNKNOWN CONTENT 335 // HANDLER COMES ONLINE!!! 336 // Until that day, if we couldn't find a handler for the content type, then go back to the listener who 337 // originated the url request and force them to handle the content....this forces us through the old code 338 // path for unknown content types which brings up the file save as dialog... which could be related...

Actually, I've just reread that bug, and this does look like a dupe.

Yes, looks like a dup to me too. Marking so. *** This bug has been marked as a duplicate of 46655 ***

thx, bz. zap.