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
Target Milestone: M13 → M14
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.