"PickApp not implemented yet" At least that's what it says when I click on the "Pick App..." button when an unrecoginized type of file is clicked on and the "What should do with this thing?" dialog comes up. (Yes, that's the technical term for that dialog :) [Nightly build of Feb. 19, 2000 for Linux/i386]

I haven't tested this on a recent build, but if this is still missing it's hard to say Mozilla is feature complete. Nominating for beta1 status. I could be wrong, but I think the powers that be should at least review it and decide.

sorry...beta1 is a keyword not a whiteboard...

Putting on PDT- radar for beta1. Will be fixed for beta2.

update component and owner.

Bill, what's the scope of this? Should you be doing it?

This bug affects *all* platforms, not just Linux.. recommend changing summary and os fields in Bugzilla. I checked this under a recent Win32 build, and looked at the XUL source. On the same dialog, the "More info.." button is also unimplemented. The dialog in question is: mozilla/xpfe/browser/resources/content/unknownContent.xul MIME-to-viewer is highly OS-dependent, and even desktop-dependent under Linux (KDE and Gnome). I will investigate the exact mechanisms in question and report back.. mozilla should use OS-defined MIME-to-viewer mappings when possible and not reinvent the wheel.

Putting on [nsbeta2+][5/16] radar. This is a feature MUST complete work by 05/16 or we may pull this feature for PR2.

Move to M19.

5/16 has come and gone with no word from Bill on this and no comment on the progress of this feature. Removing nsbeta2+ designation for new timeframe, removing beta1 kw which is long gone by now.

[nsbeta2+] This is on the exception feature list

Ben will do the first part of this with the helper application work. If he needs help, he can pass this part of the work to Bill Law.

Do we have an ETA on this exception feature?

giving this to Bill Law as he's handling this part (and has already checked in a partially working dialog)

I'm resetting this to nsbeta2-. The plan is to replace this dialog with the new "super helper app dialog" that was implemented for bug 43583. Basically, that dialog provides the "pick app" button. I'd like to still keep this bug open because there are situations in which the old unknown content dialog is still used. We need to make some minor tweaks to the uriloader to handle those. I'll use this bug to track that.

updating QA Contact

nav triage team: renamed bug to clear to suggest we remove usage of old dialog. marking nsbeta3-. If you disagree, renominate by removing nsbeta3- and describe the user scenarios that run into this problem

Use this bug to track cases where the old pickapp dialog is still thrown

Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so the queries don't get all screwed up.

PC/Linux, build 2000090308. The PickApp button has disappeared from the "Unknown File Type" dialog, but the dialog still says: "This file is unrecognized by mozilla. You can save it or open it with another application." I can't see how I'm supposed to open it with another application: "More Info..." takes you to the netscape plugin-finder page, and "Save File..." and "Cancel" do what you would expect. So currently there is a contradiction between the wording of the dialog and the offered user choices. Is this going to be resolved? By the way, I even get this "Unknown File Type" dialog after having registered a helper app for that mime type, but I assume that's another bug. If someone knows the bug number for "Helper apps not working on Linux", please post.

The old Unknown File Type dialog will be disappearing completely (replaced by the new dialog), so what you mentioned shouldn't be a problem when that happens.

I take back my comments about "Helper Apps don't work". In fact, they work without any problems when you click on a link. Great work! The only case when they don't work seems to be when the URL is manually entered in the location field: then the "Unknown File Type" comes up.

Nominating; this needs to be cleaned up ASAP. I think there's another bug (or two) somewhere that is essentially the same thing.

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

Netscape nav triage team: as per Alec Flett's pre-triage recommendation, this bug is nsbeta1-.

resetting this to nsbeta1, per conversation with alec and bill this afternoon. we do wanna take care of this issue.

Setting target milestone.

Making this one dependent on 67598 which address the uriloader/exthandler changes that remove the call to the ucth dialog. I'll leave this one open solely to address the cleanup of the build. Removing this dialog kind of makes the ucth a moot component so I'd like to see about moving the function that remains elsewhere. That's not nsbeta1, though, so I'm changing the keywords.

Moving this to 0.9. The dialog is no longer used in mozilla0.8 but there's no urgency to excise it from the build, I don't think. This component implements another interface that needs to stay around, but it is out of place being called "unknown content type handler" so it needs to be moved to a better home.

nav triage team: Not important enough to hold 0.9, resetting target milestone.

Marking nsbeta1- bugs as future to get off the radar

ucth has not been in the build since bug 156723 got fixed. This dialog is completely unused, as far as I can tell. I will cvs remove it on Tuesday night. If there is a reason for me not to, please tell me by then.

mozilla% cvs commit xpfe/browser/resources/content/unknownContent.xul Removing xpfe/browser/resources/content/unknownContent.xul; /cvsroot/mozilla/xpfe/browser/resources/content/unknownContent.xul,v <-- unknownContent.xul new revision: delete; previous revision: 1.10 done This file is no more.

vrfy'd via LXR: taint there no mo'.