316372 - mailto: links do not open Compose window anymore

Status: VERIFIED FIXED

(Core :: Networking, defect)

Description

[Michael Graubart]

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.

Comment 1

[Frank Wein [:mcsmurf]]

Also occours on Windows with a trunk build. BTW you can also test with this testcase:
data:text/html,<a href="mailto:[e-mail]">[e-mail]</a>

Comment 2

[Frank Wein [:mcsmurf]]

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

Comment 3

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

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

Comment 4

[Dave Buco]

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

Comment 5

[Michael Graubart]

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

Comment 6

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Testcase

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:[e-mail] testcases don't.

Comment 7

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

is it possible that asyncOpen now returns NS_BASE_STREAM_CLOSED here?

Comment 8

[Michael Graubart]

Attachment: e-mail, saved to disk as 'All files'.

Comment 9

[Michael Graubart]

Attachment: E-mail, saved as 'All files'.

Comment 10

[Michael Graubart]

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.

Comment 11

[Rick Stockton]

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 

Comment 12

[Boris Zbarsky [:bzbarsky]]

Attachment: Possible fix

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 13

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

Comment on attachment 204327 [details] [diff] [review]
Possible fix

we should document what available() is supposed to do in this case.

Comment 14

[Darin Fisher]

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?

Comment 15

[Darin Fisher]

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?

Comment 16

[Darin Fisher]

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.

Comment 17

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 18

[Darin Fisher]

> 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.

Comment 19

[Darin Fisher]

Attachment: v1 patch

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.

Comment 20

[Boris Zbarsky [:bzbarsky]]

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

Comment 21

[Darin Fisher]

Comment on attachment 204327 [details] [diff] [review]
Possible fix

OK, in that case, I'll check in this change for now.

Comment 22

[Darin Fisher]

fixed-on-trunk

I'll move the full cleanup patch to a new bug.

Comment 23

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED on trunk SeaMonkey build 2005-11-30-10, Windows XP, using mailto:[e-mail] and my testcase in comment 6.

Comment 24

[Lewis Rosenthal]

(In reply to comment #23)
> Verified FIXED on trunk SeaMonkey build 2005-11-30-10, Windows XP, using
> mailto:[e-mail] 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

Comment 25

[Michael Graubart]

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

Comment 26

[Lewis Rosenthal]

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

Comment 27

[Darin Fisher]

(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.

Comment 28

[Lewis Rosenthal]

(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

Comment 29

[Michael Graubart]

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

Comment 30

[Lewis Rosenthal]

(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

Comment 31

[Frank Wein [:mcsmurf]]

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