244926 - [FIX]mailto protocol is not worked when using external mailer

Status: RESOLVED FIXED

(Core Graveyard :: File Handling, defect, P1)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040527
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040527

When I click the link of mailto protocol, Mozilla said "mailto is not a
registerd protocol".
However, In the case of normal setting, this problem does not reproduce.
This problem is only reproduced when having
'user_pref("network.protocol-handler.external.mailto", true);'.

Reproducible: Always
Steps to Reproduce:
1. Create a new profile.
2. Add a "[New] -> [Boolean]" in about:config.
3. Enter network.protocol-handler.external.mailto to the preference name,
   and its value set to true.
4. Click the any link that is mailto protocol.
Actual Results:  
Mozilla said "mailto is not a registerd protocol".
And external mailer was not launched.

Expected Results:  
External mailer should be luaunched.

This problem is reproduced on trunk only,
it works fine on 1.7 branch.

Comment 1

[Met - Martin Hassman]

Is not problem in the registering of the 'mailto:' in Windows itself?
What happened when you try Srart->Run 'mailto:' -> will it start some application?

Comment 2

[Boris Zbarsky [:bzbarsky]]

See bug 11459 

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Met: My system has no problem.
It works fine from [start] -> [run]

See comment 0.
It *works fine* on 1.7 branch.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

2004052009-trunk/WinXP is good.
2004052108-trunk/WinXP is buggy.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-05-20&maxdate=2004-05-21+08%3A00%3A00&cvsroot=%2Fcvsroot

Comment 5

[David Lawhon]

This bug also occurs under MacOSX 10.3.4 with the latest daily build. So, the
Hardware and OS categories need to be changed to "All" by the Reporter of this
bug or some other empowered party.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Is this problem reproduced with Linux and BSD?
Hardware and OS to All.

Comment 7

[HARUNAGA Hirotoshi]

Linux/FreeBSD issue is Bug 194717 which is old.
But confirmed the regression on 2004052208/Mac.
Marking New.
Over to File Handling.

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

confirming win2k 2004052909

I'd suspect:
1.173	bzbarsky%mit.edu	2004-05-20 17:28	 	Blocked protocols should still allow
URI creation; they should just fail
channel creation. Bug 244220, r+sr=darin

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

eh
bz:
    if (externalProtocol || NS_FAILED(rv)) {

      // If the pref for this protocol was explicitly set to false, we want to
      // use our special "blocked protocol" handler.  That will ensure we don't
      // open any channels for this protocol.
      if (listedProtocol) {
        rv = CallGetService(NS_NETWORK_PROTOCOL_CONTRACTID_PREFIX"default-blocked",
                            result);
        if (NS_FAILED(rv)) return NS_ERROR_UNKNOWN_PROTOCOL;

That codepath seems broken. We only want default-blocked if externalProtocol is
_false_, because if it is true, we want to make sure to get the default protocol
handler, because we _want_ to get the os handler.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: Doh. Fix.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 149651 [details] [diff] [review]
Doh. Fix.

We only want to use the blocked handler if we have the protocol listed as
"don't do external".  The old code did it if it was listed at all...

Comment 12

[Boris Zbarsky [:bzbarsky]]

Fixed.