User-Agent: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.5b) Gecko/20030817 Mozilla Firebird/0.6.1 Build Identifier: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.5b) Gecko/20030817 Mozilla Firebird/0.6.1 Clicking on a mailto: link does nothing. Reproducible: Always Steps to Reproduce: 1. 2. 3. Expected Results: It should open the default email client with the mailto: email address in the To: line.

confirming

In experimental build clicking onto mail-link leads to pseudo-crash loading symbols segment violation occurred malloc_extend_top: malloc_extend_top: +015f ec075fef: * 00000005041144c7 movl $0x00000005, 0x00000004(%ecx,%edx,1) mozilla-bin:sc frame retaddr fcffc0b8 ec076519 _malloc_internal + 000004c5 fcffc0f8 ec076ff4 _malloc + 0000002c fcffc11c ec06a94f unchecked_malloc + 00000047 fcffc134 ec07351e __builtin_new + 0000001e fcffc154 eddbdf98 nsMemoryImpl::Create(nsISupports *, nsID const &, void **) + 00000098 fcffc16c edd75215 NS_GetMemoryManager + 00000031 fcffc188 8002e973 BBitmap::Bounds(void) const + 0002e973. Maybe it helps to trace problem.

I think I'm seeing this also on FB -- Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040120 Firebird/0.8.0+

WFM after applied the patch from <http://texturizer.net/firefox/faq.html#email> and removed network.protocol-handler.external.mailto=false from prefs.js (got somehow in there; after set it to true which had, of course, the same effect). Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040226 Firefox/0.8.0+ Mozilla Thunderbird 0.5+ (20040226) \V/ PointedEars

> and removed network.protocol-handler.external.mailto=false from prefs.js (got > somehow in there; after set it to true which had, of course, the same effect). Sorry, "somehow" is an insufficient explanation. I copied it from my Seamonkey profile, "false" was possibly the default there, since I had MailNews installed.

It is related to bug about removing start-script. Currently click on mailto opens Browser component instead MailNews, same happens if you try to launch MailNews immediately from command line (works on other platforms, ignored on BeOS)

> and removed network.protocol-handler.external.mailto=false from prefs.js (got > somehow in there; after set it to true which had, of course, the same effect). [Comment#5] Using Firefox Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040404 Firefox/0.8.0+ And Thunderbird Mozilla Thunderbird 0.5+ (20040403) Checking prefs (using Advanced Preferences plug-in) network.protocol-handler.external.mailto==true (default) network.protocol-handler.external.news==true (default) but mailto:whatever doesn't work.

(In reply to comment #7) > > [Comment#5] > > Using Firefox Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) > Gecko/20040404 Firefox/0.8.0+ > And Thunderbird Mozilla Thunderbird 0.5+ (20040403) > [...] > Checking prefs [...] > but mailto:whatever doesn't work. Are you sure you have also applied the mentioned patch (attached here)? PointedEars

After applied this patch (which should already work for D:\Programme\mozilla.org\Thunderbird\thunderbird.exe), you can use Start (button), Settings (menu), Control Panel, Folder Options, File Types, File Types (column): "URL:MailTo Protocol" (item), Enhanced (button) to apply to your needs.

(In reply to comment #9) > Created an attachment (id=145464) > Windows Registry patch [...] this bug is reported on BeOS

Hello, Just to confirm, I reported this as a BeOS-specific bug. Koki

re: "Hello,/Just to confirm, I reported this as a BeOS-specific bug./Koki So, I suspect we need to change the OS flag to "All". I don't have the privs.

There must be another bug somewhere for this. Maybe much more that one. Try to find this instead changing flag to All. There was even HUGE related bugzilla thread about ability to switch mozilla via preferences to another mail-client usage. So huge that all were tired of it and i don't wonder if that bug was killed at all. It just discussed problem of protocol handlers and methods to set it in Windows in prefs.js without need to create GUI settings, and supertopic about impossility to add such thing to mozilla as whole (reason - not all OS-es support such thing as OS-wide default handlers, e.g. for e-mail). And now again about BeOS specifics. We have this problem, because we use start-script for Mozilla, instead using mozilla-bin directly, and there are some other reasons which lead to fact that Mozilla in BeOS don't get proper argc transferred into proper place. As i said in comment N6.

Le'see, just a quick scan shows Bug#202497, Bug#220306, Bug#220753, Bug#241381, Bug#242255 as open mailto bugs. The following combinations are busted on MSwindows-XP: F-Fox 2004-04-25-09-trunk T-Bird 2004-04-25-00-trunk; F-Fox 2004-05-02-09-trunk T-Bird 2004-05-02-00-trunk. Under bug#220753, this was fixed once upon a time. It's baaaaack! Obviously, this stuff if fragile magic. PS, before anyone tells me to, YES the published registry patch is applied - and in fact I found another likely registry key, but it didn't work.

(In reply to comment #14) > Le'see, just a quick scan shows Bug#202497, Bug#220306, Bug#220753, Bug#241381, > Bug#242255 as open mailto bugs. My bug report is specific to BeOS, so it may not relate to the other bugs (although I would not know). BTW, I think Mozilla should just call the default email client (whatever that may be), rather than modify the MIME settings to set itself as the default email client.

Changing summary to make it clear that the bug was reported for BeOS. Prog.

Currently we try and load the prefered handler for application/x-vnd.Be.URL.[protocolscheme]. There was a bug in that code, fixed with the patch. However I'm not sure that is a standard BeOS way to specify exernal handlers, and so this patch adds a special case for "mailto" urls that uses the handler for "text/x-email" if "application/x-vnd.Be.URL.mailto" is not a registered type. Review requested.

A quick note: With the patch, moz/ff just sends the whole moz icon address line to the registerred handler. Whether or not the app deals with it is not a bezilla problem. For example, BeMail extracts just "To" and "Subject" correctly, Beam does "To", "Subject", "CC", and "BCC". Neither of them extract any "Body" text. If these are things that really annoy you, you can report them to the author of your preferred email app.

Havn't tried it but I'm not a big fan of nesting: if (protocol.IsInstalled()) *aHandlerExists = PR_TRUE; Why not just something along: *aHandlerExists = protocol.IsInstalled()

I guess the 'Reporter:' mailto-link in this bug and links in the form mailto:thesuckiestemail@yahoo.se doesn't work that well with BeMail as the to: field is not filled in. Is it supposed to work? (I have MDR 3.02 final) (I wonder why Mozilla had stolen the mailto:-mimetype for me.)

(In reply to comment #20) > I guess the 'Reporter:' mailto-link in this bug and links in the form > mailto:thesuckiestemail@yahoo.se doesn't work that well with BeMail as the to: > field is not filled in. Is it supposed to work? (I have MDR 3.02 final) Yes, that is supposed to work, and works fine for me here... odd. Try just doing "BeMail mailto:me@sever.com" from a terminal and see if it works. Do you have more than one version of BeMail around? (roster->Launch works on app sig). Also I'd delete or rename the application/x-vnd.Be.URL.mailto in filetypes if it's there, just to be sure that the code that falls back to x-email is being used (a few times I made changes that didn't seem to be used when I ran the build). On the nested thing, aHandlerExists is a PRBool, I'm not sure that (bool)true = PR_TRUE.

Comment on attachment 174501 [details] [diff] [review] Special case handling for mailto URLs Ok, full rebuild needed. Seems to work fine.

> On the nested thing, aHandlerExists is a PRBool, I'm not sure that (bool)true = > PR_TRUE. I didn't mean that code literally, but something in the line of PRBool( boolean ) or so should work. Using if's with a boolean expression to set a boolean expression just feels so over complicated to me.

(In reply to comment #23) > > On the nested thing, aHandlerExists is a PRBool, I'm not sure that (bool)true = > > PR_TRUE. > > > I didn't mean that code literally, but something in the line of PRBool( boolean > ) or so should work. Using if's with a boolean expression to set a boolean > expression just feels so over complicated to me. PRBool is defined as an integer, and PR_TRUE = 1, PR_FALSE = 0. I'm not sure, but I don't think a bool cast to an integer is guaranteed to be 1 when true, just non-zero IIRC. I can try it out though. I agree it seems like overkill, I was coping similar case from that file already, and a bit unsure on the different types issue.

Maybe it's better to just let it be. It's just one of my pet peeves.

Simon, shouldn't we close this one soon :)

(Added Simon as CC). Simon, see my previous bug-comment.

Yeh should do. Forgot I wasn't cc'ed. Patch still looks fine to me - it's all BeOS-only code so Sergei can probably check it in.

Dunno if we are allowed that outside beos-dirs in widget and gfx. Sergei do you know?

As far as i got from old Marcia Knous e-mail, i'm allowed for checkins in BeOS-dirs only. Another problem is that i didn't set yet here in NYC adequate for Mozilla BeOS environment, incl. pipe-fs by mmu-man, required to workaround ssh-cvs BeOS bug.

adding dependency to firefox 1.1 tracking bug

Comment on attachment 174501 [details] [diff] [review] Special case handling for mailto URLs Should be ok: BeOS-only change...

I really want this bug in. I hope it does get approved soon.

Talk to Asa on IRC. You'll get a quicker answer. Prog.

Comment on attachment 174501 [details] [diff] [review] Special case handling for mailto URLs a=asa

Bug 220753 mailto: links do not work on BeOS patch by simontaylor2@gawab.com r=thesuckiestemail@yahoo.se a=asa Checked in by timeless