428658 - "network.protocol-handler.app.mailto" users need to edit/remove mimeTypes.rdf

Status: NEW

(Firefox :: File Handling, defect)

Description

[Wolf Wiegand]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.9b5) Gecko/2008032601 Iceweasel/3.0b5 (Debian-3.0~b5-1)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.9b5) Gecko/2008032601 Iceweasel/3.0b5 (Debian-3.0~b5-1)

I have network.protocol-handler.app.mailto set to '~/bin/mailto.sh', which worked find for me with iceweasel/firefox 2.0. With Firefox 3.0, when clicking on a mailto-Link, evolution is called to compose the message, my mailto.sh-script is not executed.

Reproducible: Always

Steps to Reproduce:
1. Set network.protocol-handler.app.mailto to an external program/script
2. Browse to a page which contains an mailto-Link
3. Click this link
Actual Results:  
Evolution is started to compose the message.

Expected Results:  
Call the script specified in network.protocol-handler.app.mailto

Comment 1

[fswl1234]

i think they changed it all to mimeTypes.rdf, funny thing is it's still honored *in a way*

when i click an ed2k:// link, it just says "unknow ...." or something like that but does NOT ask me what i want to handle it with
playing with network.protocol-handler.external.ed2k & network.protocol-handler.expose.ed2k doesn't help
however with network.protocol-handler.app.ed2k set to /usr/bin/ed2k it triggers a dialog
then i can tell it again in this dialog, to use /usr/bin/ed2k
and it's saved in mimeTypes.rdf

Comment 2

[Mike Hommey [:glandium]]

It is possibly a dupe of bug 423776

Comment 3

[cmtalbert]

Yes, on Linux we used to use those preferences to control these actions, but these have been refactored into a cross-platform solution for Firefox 3.  I think there is still a way to do this, using the network.protocol-handler.external.* preferences and mime-types.rdf.  

I'm CCing dmose as he'll have the complete story on how to achieve this and might have ideas on how to make this easier.

Comment 4

[Max Waterman]

ok, to fix the problem for me, I found the mimeTypes.rdf that applied to my profile[1], removed all the references to ed2k (that's the protocol I was having trouble with), quit firefox, saved it, and restarted firefox. When I then clicked on an ed2k link, it popped up a window asking how it should be handled, and I manually located the /usr/bin/ed2k program, and clicked 'always use this' (or whatever the words were).

It now works correctly.

Comment 5

[Gökçen Eraslan]

I can reproduce this bug with Firefox 3.0.1 in Pardus 2008 Linux distro. I use a python script to pass necessary options (CC, BCC etc.) to kmail, and use this script (named kmail-firefox) to handle "mailto:" URLs. 

When I search kmail-firefox in strace output, I found this:

10618 read(13, "\0\0\0\0\0\0\23\310\0\0\1\234\7\0\255\336\306\0\0\0\22\0\0\0\264\20\0\0\37\0\0\0"..., 98304) = 98304
10618 access("/usr/lib/MozillaFirefox/kmail-firefox", F_OK) = -1 ENOENT (No such file or directory)
10618 access("/usr/lib/MozillaFirefox/kmail-firefox", F_OK) = -1 ENOENT (No such file or directory)
10618 access("/usr/kde/3.5/bin/kmail-firefox", F_OK) = -1 ENOENT (No such file or directory)
10618 access("/usr/local/bin/kmail-firefox", F_OK) = -1 ENOENT (No such file or directory)
10618 access("/usr/bin/kmail-firefox", F_OK) = 0
10618 access("/usr/bin/kmail-firefox", F_OK) = 0
10618 access("/usr/bin/kmail-firefox", X_OK) = 0
10618 access("/usr/lib/MozillaFirefox/kmail-firefox", F_OK) = -1 ENOENT (No such file or directory)
10618 access("/usr/lib/MozillaFirefox/kmail-firefox", F_OK) = -1 ENOENT (No such file or directory)
10618 access("/usr/kde/3.5/bin/kmail-firefox", F_OK) = -1 ENOENT (No such file or directory)
10618 access("/usr/local/bin/kmail-firefox", F_OK) = -1 ENOENT (No such file or directory)
10618 access("/usr/bin/kmail-firefox", F_OK) = 0
10618 write(11, "\372", 1)              = 1


So, checking whether script exists and is executable work great. But, Firefox does not execute the script.

Comment 6

[Jim]

"network.protocol-handler.app.mailto" worked well in FF2, not at all in FF3.  I want to use kmailservice as string data, but it is ignored in FF3. I've seen this behavior on kubuntu and openSUSE.  This feature is broken in FF3 and no easy fix at user level available.  FF should play nicer with kde.

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

Comment #1 is exactly correct.  The obscure preference use was completely replaced by the ability to drive this from the UI (which is currently persisted in mimeTypes.rdf).

The fact that it's necessary to remove an existing mimeTypes.rdf bug for previous users of this functionality is the bug here.

Comment 9

[cmtalbert]

There have been issues with these preferences since the beginning of the re-work of the mime handling in 3.0.  Can we get these issues addressed in a 1.9.0.x or 3.1 build?  

Setting wanted-? flags on both.

Comment 10

[Shlomi Fish]

I've also been bitten by this bug (Mandriva Linux Cooker). To fix it, I used Edit -> Preferences -> Applications -> mailto and selected the appropriate application.

Regards,

-- Shlomi Fish

Comment 11

[Gustavo Homem]

(In reply to comment #10)
> I've also been bitten by this bug (Mandriva Linux Cooker). To fix it, I used
> Edit -> Preferences -> Applications -> mailto and selected the appropriate
> application.
 
That doesn't fix it for shipping a default setting that applies by default to all users.

I find manually editing mimeType.rdf a regression from the previous situation.

Comment 12

[Vincent Lefevre]

(In reply to comment #10)
> I've also been bitten by this bug (Mandriva Linux Cooker). To fix it, I used
> Edit -> Preferences -> Applications -> mailto and selected the appropriate
> application.

This doesn't fix anything here.

Comment 13

[Gustavo Homem]

Is this being looked at for 3.1?

What is the suggested procedure for packaging default associations?

Comment 14

[Daniel Veditz [:dveditz]]

Once this is fixed in 3.1 or trunk we can see if the fix is in scope for a 3.0.x update

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

Support for migrating obscure preferences won't block this, though we'd take a well tested patch.

dmose: does this belong here or some other component?

Comment 16

[Dan Mosedale (:dmosedale, :dmose)]

It's conceivable that it really belongs in Core: File Handling, but all the comments here seem to be about Firefox.  I suspect it won't make much difference where the bug lives.