mailto: links do not open Compose window anymore

VERIFIED FIXED in mozilla1.9alpha1

Status

()

Core
Networking
--
major
VERIFIED FIXED
12 years ago
12 years ago

People

(Reporter: Michael Graubart, Assigned: Darin Fisher)

Tracking

({regression})

Trunk
mozilla1.9alpha1
regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9a1 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(5 attachments)

(Reporter)

Description

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

12 years ago
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>
Keywords: regression
OS: MacOS X → All
Hardware: Macintosh → All

Comment 2

12 years ago
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
Assignee: general → darin
Component: General → Networking
Product: Mozilla Application Suite → Core
QA Contact: general → benc
Summary: Clicking on e-mail link does not open Mail → mailto: links do not open Compose window anymore
Version: unspecified → Trunk

Updated

12 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
not impossible... mailto: urls use an input stream channel: http://lxr.mozilla.org/seamonkey/source/mailnews/compose/src/nsSmtpService.cpp#346
Severity: normal → major

Comment 4

12 years ago
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
(Reporter)

Comment 5

12 years ago
Here is another webpage where the 'mail to' links don't work: <http://www.savastore.com/products/contact/>.
Created attachment 203696 [details]
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:foo@bar.com testcases don't.
is it possible that asyncOpen now returns NS_BASE_STREAM_CLOSED here?
(Reporter)

Comment 8

12 years ago
Created attachment 203797 [details]
e-mail, saved to disk as 'All files'.
(Reporter)

Comment 9

12 years ago
Created attachment 203799 [details]
E-mail, saved as 'All files'.
(Reporter)

Comment 10

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

12 years ago
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 
Flags: blocking1.9a1+
Created attachment 204327 [details] [diff] [review]
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).
Attachment #204327 - Flags: superreview?(darin)
Attachment #204327 - Flags: review?(cbiesinger)
Blocks: 312760
Comment on attachment 204327 [details] [diff] [review]
Possible fix

we should document what available() is supposed to do in this case.
Attachment #204327 - Flags: review?(cbiesinger) → review+
(Assignee)

Comment 14

12 years ago
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?
(Assignee)

Updated

12 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.9alpha
(Assignee)

Comment 15

12 years ago
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?
(Assignee)

Comment 16

12 years ago
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.
(Assignee)

Comment 18

12 years ago
> 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.
(Assignee)

Updated

12 years ago
Blocks: 318185
(Assignee)

Comment 19

12 years ago
Created attachment 204499 [details] [diff] [review]
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.
Attachment #204327 - Attachment is obsolete: true
Attachment #204499 - Flags: superreview?(bzbarsky)
Attachment #204499 - Flags: review?(cbiesinger)
Attachment #204327 - Flags: superreview?(darin)
I'll try to get to this before the 12th, but if I don't it might not be until the new year...
(Assignee)

Comment 21

12 years ago
Comment on attachment 204327 [details] [diff] [review]
Possible fix

OK, in that case, I'll check in this change for now.
Attachment #204327 - Attachment is obsolete: false
Attachment #204327 - Flags: superreview+
(Assignee)

Comment 22

12 years ago
fixed-on-trunk

I'll move the full cleanup patch to a new bug.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Verified FIXED on trunk SeaMonkey build 2005-11-30-10, Windows XP, using mailto:foo@bar.tld and my testcase in comment 6.
Status: RESOLVED → VERIFIED

Comment 24

12 years ago
(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
(Reporter)

Comment 25

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

Comment 26

12 years ago
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
(Assignee)

Comment 27

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

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

(Reporter)

Comment 29

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

Comment 30

12 years ago
(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
Attachment #204499 - Flags: superreview?(bzbarsky)
Attachment #204499 - Flags: review?(cbiesinger)
*** Bug 319673 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.