Closed Bug 28584 Opened 20 years ago Closed 17 years ago

[FIXr]Remove old pickapp dialog from build


(SeaMonkey :: UI Design, defect, P1)



(Not tracked)



(Reporter: niles, Assigned: bzbarsky)


(Blocks 1 open bug, )



(1 file)

"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.
Whiteboard: beta1
sorry...beta1 is a keyword not a whiteboard...
Keywords: beta1
Whiteboard: beta1
Putting on PDT- radar for beta1.  Will be fixed for beta2.
Keywords: beta2
Whiteboard: [PDT-]
update component and owner.
Assignee: cbegle → law
Component: Browser-General → XPApps
Bill, what's the scope of this?  Should you be doing it?
Priority: P3 → P2
Target Milestone: --- → M16
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:


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

Keywords: nsbeta2
Keywords: beta2
Summary: PickApp not implemented yet (on Linux) → PickApp not implemented yet
Whiteboard: [PDT-] → [PDT-] [FEATURE]
Putting on [nsbeta2+][5/16] radar.  This is a feature MUST complete work by 
05/16 or we may pull this feature for PR2.
Whiteboard: [PDT-] [FEATURE] → [nsbeta2+][5/16][PDT-] [FEATURE]
Move to M19.
Target Milestone: M16 → 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.
Keywords: beta1
Summary: PickApp not implemented yet → [FEATURE] PickApp not implemented yet
Whiteboard: [nsbeta2+][5/16][PDT-] [FEATURE] → [PDT-] [FEATURE]
[nsbeta2+] This is on the exception feature list
Whiteboard: [PDT-] [FEATURE] → [nsbeta2+] [FEATURE]
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.
Assignee: law → ben
Target Milestone: M19 → M17
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)
Assignee: ben → law
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.
Whiteboard: [nsbeta2+] [FEATURE] → [nsbeta2-] [FEATURE]
updating QA Contact
QA Contact: asa → sairuh
Component: XP Apps → XP Apps: GUI Features
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
Summary: [FEATURE] PickApp not implemented yet → [FEATURE] Remove old pickapp dialog from build
Whiteboard: [nsbeta2-] [FEATURE] → [nsbeta2-][FEATURE][nsbeta3-]
Use this bug to track cases where the old pickapp dialog is still thrown
Keywords: meta
Depends on: 47203
Depends on: 47204
Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so 
the queries don't get all screwed up.
Keywords: nsbeta3
Depends on: 48659
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.
Keywords: meta, nsbeta2, nsbeta3nsbeta1
OS: Linux → All
Hardware: PC → All
Summary: [FEATURE] Remove old pickapp dialog from build → Remove old pickapp dialog from build
Whiteboard: [nsbeta2-][FEATURE][nsbeta3-]
*** 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-.

Keywords: nsbeta1nsbeta1-
resetting this to nsbeta1, per conversation with alec and bill this afternoon.
we do wanna take care of this issue.
Keywords: nsbeta1-nsbeta1
Blocks: 40098
Setting target milestone.
Target Milestone: M17 → mozilla0.8
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.
Depends on: 67598
No longer depends on: 47203, 47204, 48659
Keywords: nsbeta1nsbeta1-
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.
Target Milestone: mozilla0.8 → mozilla0.9
nav triage team:

Not important enough to hold 0.9, resetting target milestone.
Target Milestone: mozilla0.9 → ---
Marking nsbeta1- bugs as future to get off the radar
Target Milestone: --- → Future
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.
Assignee: law → bzbarsky
Priority: P2 → P1
Summary: Remove old pickapp dialog from build → [FIXr]Remove old pickapp dialog from build
Target Milestone: Future → mozilla1.3beta
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  <-- 
new revision: delete; previous revision: 1.10

This file is no more.
Closed: 17 years ago
Resolution: --- → FIXED
vrfy'd via LXR: taint there no mo'.
QA Contact: sairuh → petersen
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.