35744 - Sending a message with an invalid embedded image URL hangs

Status: VERIFIED FIXED

(MailNews Core :: Internationalization, defect, P3)

Description

[ji]

This is a Linux only problem. 

When replying in HTML to a message with a Japanese html attachment, clicking 
on Send button or selecting File | Send on the reply compose window doesn't
send the reply msg out. The reply compose window just doesn't exit by doing
these actions.

Steps of reproduce:
0. Set msg compose format to "Compose messages using html" from Edit | Mail/News
   Account Settings.
1. Have a msg with a Japanese html attachment in your mailbox.
2. Highlight the msg and clicking on Reply
3. Click on Send or Select File | Send

You'll see the reply msg can't be sent out. The reply window still exists after
flashing.

Notes:
1. Reply to a ASCII attachment won't have this problem.
2. Reply in plain text format won't have this problem.
3. Reply to a Japanese TEXT attachment won't have this problem.
4. It looks like a regression of fix to bug 34859. But changing charset 
   on the reply compose window doesn't make any difference.

Comment 1

[ji]

The mail box shown at the above URL contains a few messages with JPN attachment.
The 2nd one is a msg with Japanese HTML attachment. Replying to this one, 
you can see the problem.

Comment 2

[ji]

It only happens when replying to a message with a local html attachment.
It DOESN'T happen when replying to a message sent out by using "File | Send 
Page".

Comment 3

[ji]

This starts to happen from as early as 2000032409-M15.

Comment 4

[nhottanscp]

Adding rhp to cc.
Quoting seems to be OK but message cannot be sent depends on how the original 
message was sent. Rich, is that possible that reply send is affected by the 
format of the original message?

Comment 5

[nhottanscp]

I can reproduce this in windows (I will attach the data) too.
nsMsgAttachmentHandler::SnarfMsgAttachment returns NS_ERROR_INVALID_ARG after 
failing PL_strcasestr(m_uri, "_message:") where m_uri is NULL (I'll attach the 
call stack).
BTW, I found that the HackAttachments return int while everybody else return 
nsresult. The error code may be casted differently depends on the platform.

Comment 6

[nhottanscp]

Attachment: caller stack

Comment 7

[nhottanscp]

Attachment: reply the last message with HTML to reproduce

Comment 8

[rhp (gone)]

I haven't touched any of this code. I hate regressions. 

- rhp

Comment 9

[ji]

This is original found with M15 build, but it's also occurring on M16 build. (2000042009 linux commercial build).
Added nsbeta2 keyword.

Comment 10

[Katsuhiko Momoi]

QA contact to ji.

Comment 11

[rhp (gone)]

Actually, this affects all the platforms.

- rhp

Comment 12

[rhp (gone)]

Ok, this is now fixed. The fix here is to make the send operation more 
tolerant. It may result in certain embedded objects not being correct, but we 
will make a best effort to send the the message in whole.

- rhp

Comment 13

[rhp (gone)]

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

Comment 14

[ji]

I'd like to reopen it since I still see the problem on today's linux build.
(2000063008 comm), but not on today's windows build.

Comment 15

[rhp (gone)]

Is it with the same message as before or a different one? I need a specific 
example for this issue.

- rhp

Comment 16

[Katsuhiko Momoi]

ji in on vacation -- I checked the above test file and I see that the
2nd one from top (out of 4) still exibits the same problem reported
initially.

Comment 17

[Gary Liu]

this problem also occurs in windows.

Comment 18

[rhp (gone)]

How exactly is this failing and can you give me the subject of the problem 
message. I seem to have this working on my machine :-(

- rhp

Comment 19

[Katsuhiko Momoi]

Referring to the file above at the indicated URL, it is the 2nd message 
from the top whe you sort the messages by date which causes
this problem on Linux.
I'll attach a jpeg image to show which message has this problem.

The phenomenon is like this:

1. Select this message to display.
2. Under the HTML mail send option, engage the Reply button.
3. The compose window with the original mail content
   quoted come up.
4. Now simply click on the Send button. Absoluetly nothing happens.
5. The first thing you noitce is that the compose window stays 
   immobile and does not go away. And the message does not go out.

Additional facts:

6. I noticed that on Linux I can get the compose to window to "re-act" to
   the clicking of "Send" button if I re-select the "From: " address
   which is already showing my address. But even if I do this,
   the mail does nto go out and I never receive this message.

----
On Windows,

At step 4, the compose window goes away but the message does not seem
to go out at all. (i.e. I don't receive this message even though 
I receiveother msgs sent later from the same client.)

Comment 20

[Katsuhiko Momoi]

Attachment: Image showing the problem message in a highlight

Comment 21

[David :Bienvenu]

Rich, I have an idea about what might possibly be going on, because I had a
similar problem. Basically, I tried to follow a link and got an bad/empty entry
in the disk cache - forever after that, I couldn't load that url - it just spun
forever. Once I cleared the disk cache, it worked again. I wonder if that's
what's happening with your invalid url - it's getting stuck in the disk cache.
You might try clearing the disk cache after reading the message but before
replying to it, and see if that helps you get some sort of notifications.

Comment 22

[rhp (gone)]

Hmm...that was a good idea, but it still hangs. I can actually just create an 
HTML mail message...insert an image...type in the URL: http://bogus/link.gif 
and it will hang the same way :-(

- rhp

Comment 23

[rhp (gone)]

This is really not an I18N issue so I am changing the bug summary. This seems 
to be a necko/mailnews issue. If you create an HTML message and then add an 
image with a bogus URL (http://foo/bar.gif), we will try to resolve the image 
when you hit send. The problem is that:

nsURLFetcher::OnStopRequest(nsIChannel *aChannel, nsISupports * /* ctxt */, 
nsresult aStatus, const PRUnichar* aMsg)

is never called. This routine is in:

http://cvs-mirror.mozilla.org/webtools/lxr/source/mailnews/compose/src/nsURLFet
cher.cpp

Gagan: Can you help me figure out what is going on here?

Thanks!

- rhp

Comment 24

[Scott MacGregor]

If I bounce off zero bugs before Rich does I'll help take a look at this one. 

Comment 25

[Scott MacGregor]

I took a look at this tonight and I have a fix. Rich, one thing came up out of
this though. After I fixed it, I now get an alert for each url we fail to fetch
before we send the message. This makes sending messages with invalid urls really
painful. My example had 8 images with bogus urls. I had to wait for us to
timeout connecting to the server ('cause it doesn't exist), then I got an alert
saying "Unable to fetch the url: foo. Do you still wish to proceed with the
sending?" I said yes, then I got the same dialog 7 more times.

Can we throw a boolean on the consumer of the url fetcher so we only ask you
once? That would make this a lot more useable  I think.

I'll post my fix to this report.

Taking from rhp. 

Comment 26

[Scott MacGregor]

Rich, I checked in the fix for this bug tonight. However, if you could squeeze
in some protection to only through that dialog once instead of for every url we
fail to load then I think the world would be much happier. We could use this bug
to  check it in under.

Comment 27

[rhp (gone)]

Hi Scott,
Thanks for the help here. Sure I'll keep a boolean member var and only ask once 
per email.

By the way, 4.x will ask you N times in this exact situation :-o

- rhp

Comment 28

[Scott MacGregor]

Hey Rich, in that case if you have more important things to do, stay focused on
those for beta2 and we can forget this dialog issue....

Comment 29

[rhp (gone)]

If the prompt fix is simple, I'll get it in this weekend...if not, I'll punt.

- rhp

Comment 30

[rhp (gone)]

Looked at this over the weekend. It's a bit more work than I was hoping since 
the object that is putting up the prompt is an object that is 1 - per - 
attachment. I would have to keep track at a level above and pass it down into 
the attachment object.

Pizzarro drops back to punt ;-) 

Comment 31

[ji]

Retested with latest builds. I can't reply the problem message in HTML.
Steps of reproduce:
0. Configure the account to be able to compose message in HTML.
1. Highlight the problem message shown in 07/05/00 attachment.
2. Click on Reply button.
3. Click on Send button.
4. Select any option of formats (Plain text and HTML, or Plain text only, or
HTML only), then click on Send.

A confirm window comes up with the following message:
There was a problem including the file http://images2/deptlogo.gif in the
message. Would you like to continue sending the message without the file?

The message still can't get sent even if I choose OK.

There is no such a problem if I bring up the reply window in plain text mode.
Reopened the bug.

Comment 32

[Scott MacGregor]

What platform are you testing on? What build version?

Using win nt 7/24 release build this works for me. I get the dialog saying we
had a problem. I hit okay and the message is sent. 

Comment 33

[ji]

I tested with win32 2000-07-24-09 and linux 2000-07-25-08 on Japanese NT 4.0 and 
Japanese RH6.2
I get another confirm window with the same message after I hit OK.

Comment 34

[Scott MacGregor]

Right, you need to dismiss all of these dialogs. We ask you once per url that we
can't fetch (see my comments above).

If you dimiss all of them it will get sent. This example message is a pain
'cause there are so many urls we can't fetch.

Please let me know if the message isn't sent after you pass through all these
dialogs. It is still getting sent for me. 

Comment 35

[ji]

Yes, that's right. After answering several dialog windows, the reply has finally 
been sent out. 

Comment 36

[ji]

Marked it as verified.