Closed Bug 35744 Opened 25 years ago Closed 24 years ago

Sending a message with an invalid embedded image URL hangs

Categories

(MailNews Core :: Internationalization, defect, P3)

x86
All

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: ji, Assigned: mscott)

References

()

Details

(Keywords: regression, Whiteboard: [nsbeta2+] ETA: 7/13)

Attachments

(3 files)

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.
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.
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".
This starts to happen from as early as 2000032409-M15.
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?
Status: NEW → ASSIGNED
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.
Assignee: nhotta → rhp
Status: ASSIGNED → NEW
Keywords: regression
Attached file caller stack (deleted) —
I haven't touched any of this code. I hate regressions. - rhp
Status: NEW → ASSIGNED
Target Milestone: --- → M18
This is original found with M15 build, but it's also occurring on M16 build. (2000042009 linux commercial build). Added nsbeta2 keyword.
Keywords: nsbeta2
Whiteboard: [nsbeta2+]
QA contact to ji.
QA Contact: momoi → ji
Target Milestone: M18 → M17
Actually, this affects all the platforms. - rhp
OS: Linux → All
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
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
*** Bug 31693 has been marked as a duplicate of this bug. ***
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Is it with the same message as before or a different one? I need a specific example for this issue. - rhp
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.
this problem also occurs in windows.
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
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.)
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.
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
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
Summary: [Regression]Can't reply in HTML to a message with a JPN HTML attachment → Sending a message with an invalid embedded link hangs
Summary: Sending a message with an invalid embedded link hangs → Sending a message with an invalid embedded image URL hangs
Whiteboard: [nsbeta2+] → [nsbeta2+] ETA: 7/13
If I bounce off zero bugs before Rich does I'll help take a look at this one.
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.
Assignee: rhp → mscott
Status: ASSIGNED → NEW
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.
Status: NEW → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
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
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....
If the prompt fix is simple, I'll get it in this weekend...if not, I'll punt. - rhp
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 ;-)
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
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.
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.
Yes, that's right. After answering several dialog windows, the reply has finally been sent out.
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
Marked it as verified.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: