Title pretty much says it all. If you add Helper Apps to mozilla, they should appear in the navigator.mimeTypes object.

Browser, not engine --> DON Level 0

Ben and Matt: I'm willing to pay you for your help with bug 46135, too, but I need to sit down with Eric and Scott and you first. Anyway, I think this might have a lot to do with bug 54059.

Compare bug 60688 - "JavaScript reports MIME type missing when it is not"

Note that plugins that have been registered (eg flash or java) are correctly reported in the navigator.mimeTypes object. So this is only a problem for external helper apps.

Reporter is this still a problem in the latest nightlies?

I still see this in linux build 2000-12-05-08. confirming and changing summary slightly

This is on Windows too. In past Communicator versions the mimeTypes array also showed all of the file associations registered with Windows. These aren't there in Mozilla.

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

Any idea when will this bug get fixed?

Eric K. and Scott M.: Isn't this javascript bug and related issues blocking most if not all of the exthandler- and mimeTypes.rdf-related helper app bugs? (Except bug 54940, on which the general ecmascript interface to the exthandler mimeTypes.rdf database probably depends) Paul and Eric and Scott: Doesn't this have the greatest impact on Scott's exthandler code, and its interaction with mimeTypes.rdf? Johnny: Do you understand bug 54940? Paul and Ben and Matt: Who is in charge of Preferences module these days? The official www.mozilla.org/owners.html still says Neeti Jain. Does the appropriate preferences person understand Scott's code at all? I ask because of the plethora of dependent pref bugs blocked by this one. Thanks!

wow nice bug, all that's missing is someone to complain about mozilla telling web servers too much about localhost|localinstall.

A good point; would [privacy-concerns] not be fully addressed by making the javascript interface to mimeTypes.rdf only readable and writable by the corresponding Preferences sub-panel and whatever else needs to find or set up helper apps? That is all I'm asking!

Actually, the HTTP standard does provide for a way for a client to indicate which MIME types are "Accept"able, if I remember correctly, but of course it would be a mistake to give away the app pathnames. Scott: Wouldn't it take you only, like, ten minutes to do bug 61408 so there would be some chance that the volunteer community could make any progress at all on these things?

it's clear that web developers want access to the mime database, so just marking it chrome-only won't work. I'm fine w/ requiring scripts be signed for restricted priveleges, but that won't happen. A warning system would also be ok w/ me, but I doubt that will happen. Most browsers end up sending accept ... */*. But a pretty name "Timeless's top secret data files" is much more valuable than .tsp or private/data

> it's clear that web developers want access to the mime database That's no argument. They also want to know my name and which apps I may have pirated. Giving out the full Windows file associations indeed seems wrong or at least suspect to me, even without descriptions and paths.

So, which fields are going to be read-only, which are read-write, and which are completely protected from non-chrome access?

In navigator.mimeTypes? I think the only thing that should be readable by non-chrome code is whether a given mime-type is supported. Nothing should be writable by non-chrome code. Is there a good reason for a web developer to know anything more than whether my browser can handle a given mime-type or not?

> Is there a good reason for a web developer to know anything more than whether > my browser can handle a given mime-type or not? No. Note: "browser" is a keyword here. Why should a web-developer care, if I have MS Word (with mimetype application/mswordsomething) installed and sat up correctly on my *system* (i.e. have MS Word somehow load after clicking on these docs)? ccing mpt in case he has any comments. I know this is a general discussion. I don't know an appropriate newsgroup...

Brendan: Which navigator.mimeTypes fields do you think should be readable and/or writable by the different access realms of JavaScript? Do you know of any resources which might be helpful to do bug 61408?

http://lxr.mozilla.org/classic/source/lib/libmocha/lm_plgin.c has no access checks. Aren't we trying to be backward compatible and avoid 4xp bugs here? I don't have documentation people in my pocket to help with random code-level doc tasks. netscape.com has doc people employed generally on user-level docs. First (primary source) doc is the code. After that, try asking around on #mozilla. Maybe endico knows of someone who is game. /be

This is Thomas Ng from Sun Microsystems. I am working on Java Web Start, which we install it as a helper application for netscape. We used the javascript navigator.mimeTypes to check for whether JWS is installed. And we ran into this bug too. Can anyone tell me when will this get fixed? Is there any work around for this bug?

This needs a new owner if it needs to be fixed soon, I have no time to spend on this any time soon.

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

Have you noticed the related bug 93122 ? Strange, eh? Also: Now that "Java Web Start" begins to gain speed, it creates badwill for Mozilla that the demos here < http://java.sun.com/products/javawebstart/demos.html > do not work with Mozilla (at least not when I tried with 0.9.8 five minutes ago).

Here's a testcase directly from DevEdge that shows Nav 4.x did indeed expose all the helper apps through the navigator object. (I have 560!) Docs: http://developer.netscape.com/docs/manuals/js/client/jsref/mimetype.htm

Nominating for mozilla1.0 and clearning milestone for re-targeting because 4.x did this and we should too for true backwards compatibility.

does this include only the helper apps that are set in the actual browser or also helper apps from the system? E.g., are windows registry settings that say that TIFFs are to be opened in Photoshop reflected in the list? (the browser _does_ use those settings when looking for a helper app).

this issue is extremely severe because it blocks easy deployment of jnlp-java web start applications. fixing it would really, really help.

According to the eighteen-months-old blocking bug 58811, the fix to that one is "ten-minute task"...

Svante, you mean bug 61408. And I underestimated the "ten minutes" by a factor of eight, given that someone who would know estimates 1.5 hours.

Does anynow know if there exists an enummeration of system helper applications that can be used to fill-in this array?

Why is this not critical? What are the [privacy-concerns]? Are people really worried about sites learning what helper apps are installed? How could that be a problem?

Peter, since you seem to have some interest in seeing this fixed I'm handing this over to you for futher investigation :-) And I bet there are OS specific API's for enumerating the helper apps, and I bet those API's are used in the MozillaClassic codebase, so dig there...

Unix has no built-in API to do this. It would have to be written from scratch (or lifted from MozillaClassic, but we already have our own version of the code to parse the config files involved....). Privacy concerns absolutely involve sites knowing what helper apps I use. I believe that information should not be available to the site. Further, we already have problems with sites sniffing flash versions and getting it wrong (many sites detect Flash 6 as no flash installed). I would rather not proliferate the same problem with helpers, so the amount of information we give should, imo be minimal. Something like "exists" if a helper for a particular type exists or something.... There should be no reason to say what helper it is exactly.

On MacOS, the API to query helper applications is part of Internet Config: http://developer.apple.com/techpubs/macosx/Carbon/networkcomm/InternetConfig/internetconfig.html On Unix, you probably want to support mailcap format (documented in RFC 1524).

To clarify the Unix issue, we could create our own API (a bit of refactoring of the existing mailcap-parsing code would be needed, but not much).

Hm...well, there seems to be a way to get an ennumerator from nsIMIMEDataSource. I wonder if that can be used?

There are to my knowledge no useful implementations of nsIMIMEDataSource (except possibly no Mac).

setting to future

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

batch: adding topembed per Gecko2 document http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html

Topembed+ as this is required for Gecko 2.0.

OK. Once and for all, could we make these Gecko2 documents public or something? As one of the people who're most likely to have to implement this or review the patch, I'd like to sort of have and idea of what we're aiming for here, exactly.

Peter, Would you fix it ASAP? It will be very nice to have this fix. One of our products (Java Web start) want this fix. The javascript we use to detect whether Java Web Start is installed depends on navigator.mimeTypes object.

Please, we need that functionnality so we can detect if Java Web Start has been installed.

As I told peter in email, fixing this requires completely redesigning how we do helper apps. The current architecture is: 1) We have a type we can't handle internally 2) We look for a helper for this type 3) We launch the helper if we find it This means that at no point is there a comprehensive list of "all types that helpers exist for". Creating such a list would be somewhat difficult (eg on Windows it involves somehow enumerating all registry entries that have keys that match a certain pattern). Once such a list was created, we would need a mechanism to keep it up to date (eg get notified if any registry entry with a key that matches a certain pattern changes). We could list only the helpers from helper app preferences in navigator.mimeTypes, but I somehow doubt that installing Java Web Start puts it in helper app preferences.

Perhaps we should read the 4.x registry location (HKEY_CURRENT_USER\Software\Netscape\Netscape Navigator\Viewers) which does seem to include Java Web Start. Xiaobin, from where would you like us to read helper application information? Maybe we should open seperate bugs about implementing managing OS helper app lists per platform and integrating them with navigator.mimeTypes.

peter, you're totally missing the point. we aren't looking for where we could collect the information, there are lots of places. we aren't looking for apis, we can get them. the biggest concern is what information do we leak to web pages. xiaobin: why isn't this information available while running in the JVM? It would seem to me that you could ask the JVM about webstart. and if the JVM doesn't want to give that information out because of privacy or security concerns then that's probably a good reason for us not to give out that infromation. Heck, why not just have the java plugin register the mime type and then handle it?

From Comment #34 From Boris Zbarsky 2002-06-04 10:16: "...the amount of information we give should, imo be minimal. Something like "exists" if a helper for a particular type exists or something. There should be no reason to say what helper it is exactly." Simply returning a list of types should address privacy concerns. I believe timeless@bemail.org was mistaken in removing [4.x did this].

xiaobin would be better in anwsering that question, but with Java Web Start, there is no need for the java plugin. It's just a mime typed xml file (.jnlp files) that will be analysed by JWS. JWS can then download jar files and start the Java application. There is no Applet with this sheme, no java plugin involved. By asking for supported mime types from the browser, we can then be sure JWS is there and that it will be started. No need to start up the pluggin just for asking.

http://bugzilla.mozilla.org/describekeywords.cgi#4xp 4xp Navigator 4.x Parity bugs. A bug is a Navigator 4.x Parity bug if it occurs on Mozilla builds, but does not occur using the latest release of Netscape Communicator 4.x. The status whiteboard is for things which don't have keywords.

per comment #46, the owner of Helper Apps states that this would require a redesign. Since this really falls into that category, I am reassigning this to him and setting to future

1) I'm not the owner of helper apps -- Bill Law is. I have no interest in being the owner. 2) I also have no interest in fixing this bug. There are much bigger problems with helper apps that I would fix first if I were to work on helper apps (and I'm disinclined to even do that). 3) If we only care about it working on Windows and only care about the 4.x registry, it can probably be done without too much pain. If we decide on that course of action, someone with access to a Windows machine would have to do it (ie not me). Leaving assigned to me because I can't think of anyone to offload it on, but I have no plans to ever work on this.

Boris: I am so sorry, I have no idea why I thought you owned Helper Apps. I am going to reassign this to nobody.

So. As pointed out on n.p.m.plugins, we don't need to fill in navigator.mimeTypes. What people are really looking for is a function on the navigator object, something like: boolean isTypeSupported(in ACString aMIMEType); that will return true if a plugin or helper exists for that type or if we just handle it natively. Thoughts? I see no serious privacy issues with this approach, so if the DOM people are OK with adding this to nsIDOMNavigator we should just do it.

ok, that's good enough for me provided that caps allows for: denied, confirm, and allow.

Um.. explain? On a per-type basis? Or access to the function in general? CAPS can do allow and deny for the function.

to the function in general i guess. at some point someone needs to redo caps (as an extension) so that it allows the user to write rules based on all available information.

Well, given that CAPS is not getting "confirm" support, will allow/deny support suffice for you?

*sigh*. I want to be able to decide on a per site basis as needed whether to grant permission - java did this. This really isn't an unreasonable request (it's merely an inherent flaw of the current CAPS system) - but it's a request against caps not against helperapps so it is beyond the scope of this bug. At some point permissions will be redesigned and then someone can work caps into the permissions system. let's do it with caps and then if we get lots of flack (i know we won't) we can set the default to noaccess.

jst pointed out that |navigator.mimeTypes['major/minor']| could already be tested for true/false and is the most likely way people will use navigator.mimeTypes anyway. He also said he's fine with that returning things which are not in the array when iterated over. So that's what this patch does.

Comment on attachment 112847 [details] [diff] [review] proposed patch what do you think?

Comment on attachment 112847 [details] [diff] [review] proposed patch - In MimeTypeArrayImpl::NamedItem(): + if (!*aReturn) { How about making the loop above this code return early when a match is found to avoid this nesting? + mimeSrv->GetFromMIMEType(NS_LossyConvertUCS2toASCII(aName).get(), + getter_AddRefs(mimeInfo)); Don't do a lossy conversion here, that could in theory turn up false positives here. Imagine you have a unicode character whose low 7 bits represent a normal ASCII character (which most unicode characters do)... Use NS_ConvertUCS2toUTF8() here in stead, that way there will be no false positives. + // If we got here, we support this type! Say so. + HelperMimeTypeImpl* helperImpl = new HelperMimeTypeImpl(aName); + if (!helperImpl) { + return NS_ERROR_OUT_OF_MEMORY; + } + // XXX MimeTypeArrayImpl expects an already addrefed in param + // to the constructor! + NS_ADDREF(helperImpl); + MimeTypeElementImpl* entry = new MimeTypeElementImpl(nsnull, helperImpl); + if (!entry) { + NS_RELEASE(helperImpl); + return NS_ERROR_OUT_OF_MEMORY; + } How about making helperImpl and nsCOMPtr<nsIDOMMimeType> here? Then you wouldn't need the manual refcounting and cleanup. +// QueryInterface implementation for HelperMimeTypeImpl +NS_IMPL_ISUPPORTS1(HelperMimeTypeImpl, nsIDOMMimeType); If this needs to be scriptable, which I belive it needs to be, then you'll need some class info love here... How about making this class just extend the existing MimeTypeElementImpl class (or vice versa) and just overriding the methods you need to? That way you'd get the XPCOM fu for free. sr=jst with those changes, let me know if you want me to look at a new diff...

> Imagine you have a unicode character Those are not allowed in MIME types... but sure, I can do conversion to UTF8. > Then you wouldn't need the manual refcounting and cleanup I'd still need the manual addref (see the XXX comment), and I'd have to do something like calling NS_ADDREF on the .get() of the COMPtr... which I would really rather not introduce anywhere in our codebase. ;) > If this needs to be scriptable, It does not. That's why it's getting wrapped in a MimeTypeElementImpl... The current setup is that there are two impls of nsIDOMMimeType -- MimeTypeElementImpl is scriptable and just wraps an object implementing that interface that lives in the _plugin_ (!) code. So I'm reusing the wrapper but having it wrap a different object... All this code could use a thorough rewrite. :( Good catch on the early return; I'll do that.

Here's the same patch with these changes: 1. Checks for non-null default handler or a nonempty default handler description such that application types in the Windows registry will be found. 2. Returns from loop when item found. 3. Uses NS_ConvertUCS2toUTF8.

Arun tells me an embedding customer really needs this, renominating and --->taking

Comment on attachment 113035 [details] [diff] [review] patch v.1.1 + return NS_OK; + } + } + + if (!*aReturn) { You don't need that check, if you have that return up there.... + HelperMimeTypeImpl(const nsAString& aType) + : mType(aType) + {} This is actually in my patch too; I forgot to fix that line. The file is tab-indented, but the "{}" is space-indented. Change those two spaces to a tab? With those two nits (and assuming that you tested this on Windows and checking the path makes things happier there), r=bzbarsky on your changes to the patch. The patch still needs a review, imo; I'm not really qualified to review code which I mostly wrote myself. ;) Peter, mind doing the r= on that part?

updated patch

Comment on attachment 113051 [details] [diff] [review] patch v.1.2 r=peterl

Comment on attachment 113051 [details] [diff] [review] patch v.1.2 + // If we got here, we support this type! Say so. + HelperMimeTypeImpl* helperImpl = new HelperMimeTypeImpl(aName); + if (!helperImpl) { + return NS_ERROR_OUT_OF_MEMORY; + } + // XXX MimeTypeArrayImpl expects an already addrefed in param + // to the constructor! + NS_ADDREF(helperImpl); + MimeTypeElementImpl* entry = new MimeTypeElementImpl(nsnull, helperImpl); I still say helperImpl should be an nsCOMPtr here, and change the lame implementation of MimeTypeElementImpl to *take* ownership of what it's given, not assume it. IOW, make MimeTypeElementImpl::mMimeType a nsCOMPtr<nsIDOMMimeType> and change the callers to do the right thing. The ownership model of MimeTypeElementImpl::mPlugin is all goofy too, I bet there's a crash waiting to happen there. Wanna file a bug on that? sr=jst if you make that change.

nsbeta1+

topembed+ just because it looks like we have traction (although I don't know the specific embedding customer)

updated patch w/ jst's comments

Comment on attachment 113748 [details] [diff] [review] patch v.1.3 carrying forward reviews attempting to request drivers' approval for 1.3b: this fix is needed so JS can detect if a helper application is installed and branch accordingly. It does not allow for enummerating over all helper application, just individual mime tests.

Comment on attachment 113748 [details] [diff] [review] patch v.1.3 We're wrapped on 1.3beta. Moving request to final. Peter, is this something you feel is well tested/safe enough to land in a final "cleanup and polish" cycle or should it wait until 1.4alpha opens?

Please get this in 1.3. This is killing our use of Mozilla since we do a lot of Java Web Start.

Comment on attachment 113748 [details] [diff] [review] patch v.1.3 since this missed 1.3b and according to the roadmap, 1.4 should be open next week, I'm canceling my request for approval for this feature.

I wouldn't trust the roadmap....

I checked in the patch to the trunk last night so I'm marking this FIXED. Please open new bugs to track issue that many arise. I've opened bug 195322 to track the problem with mPlugin mentioned in comment #70. Thanks all.

Why I still can't get the helper application 's mimetype?

Mozilla1.4 still has this problem. Have this patch been checked into 1.4?

This was checked in, yes. There were some changes in nsIMIMEInfo-land recently; should this code be using hasDefaultHandler in preference to looking for a description? Or put another way, how _exactly_ are you testing this?

sorry for late, here is the testcase

Please see comment 61. The helper types are not visible when you iterate, but querying for them directly will work.

Boris, So how to get all mime type (Helper Applications and Plugins) by using javascript? Thanks a lot!

Joshua, you don't do that. Implementing it would be either a lot of work or prohibitively expensive, and no one has proposed a viable use case requiring that functionality. All the use cases mentioned in this bug work just fine with what was implemented.

For java webstart applications .jnlp needs to be connected as a helper application. Users need to know if this is already done. I try to detect it with javascript and navigator.mimeTypes['application/x-java-jnlp-file']. If mozillas bug is fixed, detection should work with mozilla1.4 or netscape 7.1. Sorry, but it doesn't work for me.

Thomas, I assume that you DO have a helper app set for that MIME type? What is the exact check you are doing?

Um...this is working just fine for me in Netscape 7.1 (and Moz 1.4) on Win32. See: javascript:alert(navigator.mimeTypes['application/x-java-jnlp-file']); This returns a mimeType object if a type is found (in the registry). Try making a mistake and you'll notice it returns undefined: javascript:alert(navigator.mimeTypes['application/x-bogus-mime-type']); You can also test if it's a plugin by looking at the .enabledPlugin property. You may NOT enummerate the array and dump all supported types of a browser but you MAY test individual types.

so this bug fixing can only let individual defined types works, can't enummerate the array and dump all supported types of a browser (include helper application)?

Exactly. If there is a serious use case for that, we could consider it, but it would require basically rewriting how Mozilla does helper apps.