Closed Bug 11281 Opened 26 years ago Closed 25 years ago

[feature] mime handler for xpi type

Categories

(Core Graveyard :: Installer: XPInstall Engine, defect, P2)

Product:
Core Graveyard
Component:
Installer: XPInstall Engine
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: cathleennscp, Assigned: dougt)

References

Details

(Whiteboard: [PDT-])

Summary: mime handler for xpi type
Summary: mime handler for xpi type → [feature] mime handler for xpi type
Blocks: 11020
Assignee: cathleen → dougt
Target Milestone: M10
we need it so that when you click on a xpi (or JAR) file in the browser, we get
to be the default handler.
We could hard-code this as another entry in nsMIMEService.cpp, but we really
need to have a more extensible solution.
for now if you want to associate a mime type w/ a file extension, hard code it
in nsMIMEService. It sounds like cathleen's talking about registering as a
content type handler which gets into the eventsink getter registration stuff.
Blocks: 12805
Target Milestone: M10 → M11
Target Milestone: M11 → M12
blocked until eventsinkgetter is more real.
Summary: [feature] mime handler for xpi type → [BLOCKED] [feature] mime handler for xpi type
Blocks: 14740
doug, any updates on this ?
Depends on: 14928
I think this is just another case of URL dispatching. URL dispatching looks at
the content type (in your case, we'll make one up for xpi files), and finds the
application to handle it (the installer).

I'm going to mark this as dependent on the URL dispatching bug (although
distinct from it) because taking care of this will still require a bit of work
after that architecture is in place.
Assignee: dougt → cathleen
assigning to cathleen for escalation.
Summary: [BLOCKED] [feature] mime handler for xpi type → [BLOCKED][DOGFOOD][feature] mime handler for xpi type
Putting on Dogfood radar for PDT review.
Summary: [BLOCKED][DOGFOOD][feature] mime handler for xpi type → [BLOCKED][BETA][feature] mime handler for xpi type
Whiteboard: [PDT-]
Putting on PDT-...putting on [BETA] radar.
Target Milestone: M12 → M13
cathleen returns for m13
Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall
Engine
Assignee: cathleen → dveditz
Reassigning
Target Milestone: M13 → M14
No time in M13
Removing PDT annotation now that dogfood nomination has been removed
Whiteboard: [PDT-]
Status: NEW → ASSIGNED
Keywords: beta1
Summary: [BLOCKED][BETA][feature] mime handler for xpi type → [feature] mime handler for xpi type
PDT+
Whiteboard: [PDT+]
PDT wants to know what we lose by not having this for B1?
Whiteboard: [PDT+]
We lose the ability to click on a link to launch a zippy install, all installs 
would have to be launched from scripted actions. Primarily this means users 
can't surf the mozilla.org (or netscape) ftp directories in order to install 
anything.
Setting second tier M14 priorities
Priority: P3 → P2
Did you put it on an anchor or put it on a button?  Still seems like a pdt 
minus.

Send additional comments directly to pdt alias if you have more info.  Thanks!
Whiteboard: [PDT-]
pdt-, pushing to m15
Target Milestone: M14 → M15
Target Milestone: M15 → M16
I need to do this same this for cert auth, I can do both at the same time...
Status: ASSIGNED → NEW
I really want this one.
Assignee: dveditz → dougt
PR2 feature.
Doug has code working last week before he went on vacation.
Keywords: nsbeta2
checked in this evening.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Build: 2000-05-09-08-M16(MAC), 2000-05-09-09-M16(WIN), 2000-05-09-08-M16(LINUX)

Click it, and the the confirmation dialog appears.  Cool.  Marking Verified!
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.