User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051113 SeaMonkey/1.5a Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051113 SeaMonkey/1.5a On this site (and possibly others), clicking on the e-mail address link fails to open a 'Compose' page in Mail. In Mozilla 1.7.12, it does. Reproducible: Always Steps to Reproduce: 1. Go to given webpage. 2. Click on link for e-mailing. Actual Results: Nothing. Expected Results: A 'Compose' page should open in SeaMonkey Mail, with the given e-mail address pre-entered. eMac G4, OS X 10.3.9, Classic theme.

Also occours on Windows with a trunk build. BTW you can also test with this testcase: data:text/html,<a href="mailto:adsf@fsd.invalid">adsf@fsd.invalid</a>

biesi: Could this Bug here be caused by Bug 312760? Broke between 2005-11-12-10 and 2005-11-13-08 Bonsai link: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-11-12+08%3A00%3A00&maxdate=2005-11-13+09%3A00%3A00&cvsroot=%2Fcvsroot

not impossible... mailto: urls use an input stream channel: http://lxr.mozilla.org/seamonkey/source/mailnews/compose/src/nsSmtpService.cpp#346

This is happening with me as well. Running Windows XP Home Edition, SP2 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051114 SeaMonkey/1.5a - Build ID: 2005111409

Here is another webpage where the 'mail to' links don't work: <http://www.savastore.com/products/contact/>.

This throws the following exception: Error: uncaught exception in the JavaScript Console: [Exception... "Component returned failure code: 0x80470002 (NS_BASE_STREAM_CLOSED) [nsIDOMLocation.href]" nsresult: "0x80470002 (NS_BASE_STREAM_CLOSED)" location: "JS frame :: file:///C:/Documents%20and%20Settings/Owner/Desktop/testcase.html :: sendEmail :: line 15" data: no] whereas regular mailto:foo@bar.com testcases don't.

is it possible that asyncOpen now returns NS_BASE_STREAM_CLOSED here?

Re ##8 & 9: I seem to have had undue difficulties with sending my comment and attachment. I tried twice, and now I see that the attachment got sent twice, but my comment isn't there. So here it is: the attachment is an e-mail received by me (saved as 'All files'). This contains a link to a website, and — just like the mail-to links that were the original subject of this bug report — it doesn't work. I am still on Mac OS X 10.3.9.

It happens on Linux (GTK2+XFT) as well... I'm running a nightly from about a week ago, and this is a regression after my previous nightly from October 31. Here's my current 'about' string: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051117 SeaMonkey/1.5a

So the problem is that mailto:, for whatever reason, creates a pipe, writes nothing to it, closes the pipe output stream, and inits an input stream channel with the input. That's the "mailto: channel", such as it is... So when we get to nsInputStreamChannel::OpenContentStream (called from nsBaseChannel::AsyncOpen), we call Available() on the stream, which throws (since mAvailable is 0 in the nsPipeInputStream, and the pipe's output is already closed). This patch does fix the bug, but I'm not sure whether it's right (and why the pipe is throwing here instead of returning 0 -- I see no indication on nsIInputStream that Available() should ever throw).

Comment on attachment 204327 [details] [diff] [review] Possible fix we should document what available() is supposed to do in this case.

Comment on attachment 204327 [details] [diff] [review] Possible fix What nsIInputStream::Available implementation is throwing NS_BASE_STREAM_CLOSED in this case? I don't think that error code should be thrown. Instead, it should be returning NS_OK and 0 bytes available. Is it the nsFileInputStream?

I see. Comment #12 answers my question. I'd prefer to fix this by documenting the interface and fixing code to not throw NS_BASE_STREAM_CLOSED from nsIInputStream::Available. Sound good?

Actually, on second thought, it may be better to have Available throw NS_BASE_STREAM_CLOSED when the stream will have no more data ever. That way, the caller can distinguish "no data right now" from "no data ever". The only other way to figure out if a stream is at EOF is to call ReadSegments, which doesn't work on streams that don't support Read. Therefore, I think the exception thrown from Available is needed. I will revise the current patch to include documentation to that affect.

> That way, the caller can distinguish "no data right now" from "no data ever". Indeed, which is why I didn't change the pipe. I wonder how many of our input streams actually do that, though... Doesn't documenting that effectively mean a small API change for nsIInputStream in that existing implementations may now become "buggy" per the interface? If we're ok with this, then documenting this would be wonderful.

> If we're ok with this, then documenting this would be wonderful. I'm working on a patch to fix existing implementations since many of them actually get it right.

OK, here's a big patch that goes through the source tree and fixes up most nsIInputStream implementations. I've also added more to the nsIInputStream documentation.

I'll try to get to this before the 12th, but if I don't it might not be until the new year...

Comment on attachment 204327 [details] [diff] [review] Possible fix OK, in that case, I'll check in this change for now.

fixed-on-trunk I'll move the full cleanup patch to a new bug.

Verified FIXED on trunk SeaMonkey build 2005-11-30-10, Windows XP, using mailto:foo@bar.tld and my testcase in comment 6.

(In reply to comment #23) > Verified FIXED on trunk SeaMonkey build 2005-11-30-10, Windows XP, using > mailto:foo@bar.tld and my testcase in comment 6. > Confirmed that testcase is FIXED in SeaMonkey build 2005-11-30-07, OS/2. Unfortunately, I can't for the life of me recall what live link I hit the other day which prompted me to stop by this bug... Lewis

Works on Build No. 2005113010 (Mac) (eMac G4, OS X 10.3.9) also.

Hmmm... Regression bug? With the aforementioned 2005-11-30-07 SeaMonkey build on OS/2, I'm getting the following crash (consistently) when sending email: 11-30-2005 16:42:00 SYS3175 PID 008b TID 0001 Slot 00c8 J:\MOZILLA.ORG\SEAMONKEY\SEAMONKEY.EXE c0000005 14e67d51 P1=00000001 P2=72505c69 P3=XXXXXXXX P4=XXXXXXXX EAX=72505c61 EBX=00000000 ECX=04cebe24 EDX=04cebe20 ESI=00659a60 EDI=0132b284 DS=0053 DSACC=f0f3 DSLIM=ffffffff ES=0053 ESACC=f0f3 ESLIM=ffffffff FS=150b FSACC=00f3 FSLIM=00000030 GS=0000 GSACC=**** GSLIM=******** CS:EIP=005b:14e67d51 CSACC=f0df CSLIM=ffffffff SS:ESP=0053:0011e4e0 SSACC=f0f3 SSLIM=ffffffff EBP=0011e598 FLG=00012202 MSGCOMPO.DLL 0001:00047d51 If you guys think this is unrelated, I'll file a separate bug for it (or check in the ng to get some consensus). Lewis

(In reply to comment #26) > Hmmm... Regression bug? With the aforementioned 2005-11-30-07 SeaMonkey build > on OS/2, I'm getting the following crash (consistently) when sending email: sounds unrelated to me. maybe the fix exposed some other bug.

(In reply to comment #27) > (In reply to comment #26) > > Hmmm... Regression bug? With the aforementioned 2005-11-30-07 SeaMonkey build > > on OS/2, I'm getting the following crash (consistently) when sending email: > > sounds unrelated to me. maybe the fix exposed some other bug. > Thanks, Darin. So far, I've got what may be a confirmation of the behavior form another OS/2 user (I haven't tried on another system here). If this is indeed unrelated to this patch, then I sincerely apologize to everyone for the bugspam. Lewis

On Build 2005113010 (Mac, OS X 10.3.9) I have not had any crash problems (yet?).

(In reply to comment #28) > (In reply to comment #27) > > (In reply to comment #26) > > > Hmmm... Regression bug? With the aforementioned 2005-11-30-07 SeaMonkey build > > > on OS/2, I'm getting the following crash (consistently) when sending email: > > > > sounds unrelated to me. maybe the fix exposed some other bug. > > > Thanks, Darin. So far, I've got what may be a confirmation of the behavior form > another OS/2 user (I haven't tried on another system here). > > If this is indeed unrelated to this patch, then I sincerely apologize to > everyone for the bugspam. > Yeah, evidently something else. The 2005-12-01 1.5a OS/2 nightly works fine, and I can verify that the testcase is indeed working. Lewis

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