The default bug view has changed. See this FAQ.

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

NEW
Unassigned

Status

()

Firefox
File Handling
9 years ago
8 years ago

People

(Reporter: Wolf Wiegand, Unassigned)

Tracking

unspecified
x86
Linux
Points:
---
Bug Flags:
blocking-firefox3.5 -
wanted-firefox3.5 +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
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

9 years ago
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

It is possibly a dupe of bug 423776

Comment 3

9 years ago
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

9 years ago
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

9 years ago
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

9 years ago
"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 #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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: "network.protocol-handler.app.mailto" not honored → "network.protocol-handler.app.mailto" users need to edit/remove mimeTypes.rdf

Updated

9 years ago
Duplicate of this bug: 446481

Comment 9

9 years ago
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.
Flags: wanted1.9.0.x?
Flags: wanted-firefox3.1?

Comment 10

9 years ago
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

9 years ago
(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

9 years ago
(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

9 years ago
Is this being looked at for 3.1?

What is the suggested procedure for packaging default associations?
Once this is fixed in 3.1 or trunk we can see if the fix is in scope for a 3.0.x update
Flags: wanted1.9.0.x? → blocking-firefox3.1?
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?
Flags: wanted-firefox3.1?
Flags: wanted-firefox3.1+
Flags: blocking-firefox3.1?
Flags: blocking-firefox3.1-
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.
You need to log in before you can comment on or make changes to this bug.