28584 - [FIXr]Remove old pickapp dialog from build

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P1)

Description

[Rick Niles]

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

Comment 1

[Rick Niles]

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.

Comment 2

[Rick Niles]

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

Comment 3

[leger]

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

Comment 4

[Christine Begle]

update component and owner.

Comment 5

[don]

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

Comment 6

[Mark Heily]

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.

Comment 7

[leger]

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

Comment 8

[don]

Move to M19.

Comment 9

[Blake Ross]

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.

Comment 10

[Peter Trudelle]

[nsbeta2+] This is on the exception feature list

Comment 11

[don]

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.

Comment 12

[Joseph Elwell]

Do we have an ETA on this exception feature?

Comment 13

[Ben Goodger (use ben at mozilla dot org for email)]

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

Comment 14

[Bill 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.

Comment 15

[Asa Dotzler [:asa]]

updating QA Contact

Comment 16

[johng]

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

Comment 17

[Blake Ross]

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

Comment 18

[Daniel Veditz [:dveditz]]

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

Comment 19

[Andreas Franke (gone)]

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.

Comment 20

[Blake Ross]

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.

Comment 21

[Andreas Franke (gone)]

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.

Comment 22

[Bill Law]

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

Comment 23

[Bill Law]

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

Comment 24

[Marcia Knous [:marcia]]

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

Comment 25

[sairuh (rarely reading bugmail)]

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

Comment 26

[Bill Law]

Setting target milestone.

Comment 27

[Bill Law]

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.

Comment 28

[Bill Law]

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.

Comment 29

[Paul Chen]

nav triage team:

Not important enough to hold 0.9, resetting target milestone.

Comment 30

[Paul Chen]

Marking nsbeta1- bugs as future to get off the radar

Comment 31

[Boris Zbarsky [:bzbarsky]]

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.

Comment 32

[Boris Zbarsky [:bzbarsky]]

Attachment: xpfe/browser/resources/content/unknownContent.xul in its current state

Comment 33

[Boris Zbarsky [:bzbarsky]]

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.

Comment 34

[sairuh (rarely reading bugmail)]

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