Closed Bug 88079 Opened 23 years ago Closed 23 years ago

Cannot send message that contains file:// hyperlink

Categories

(MailNews Core :: Composition, defect, P1)

x86
Windows 98
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.5

People

(Reporter: jonrubin, Assigned: bugzilla)

References

Details

(Keywords: crash, Whiteboard: PDT+)

Attachments

(3 files, 2 obsolete files)

Found on 6.1b build using Win98-US.

When trying to send a message that contains a file:// hyperlink, the following
behavior was observed:

If selecting "Send in Plaintext and HTML", the application crashed.
If selecting "Send in Plaintext only", a "Send Failure" error message was
generated, but no crash.
If selecting "Send in HTML Only", the application crashed.

Note that each time a crash occurred, I sent a Talkback message (about a dozen
generated 30 minutes ago).

Please see bug 87758 for info about a problem where clicking the file://
hyperlink in a mail message has no effect.
Just got a crash when trying to send as "Plaintext Only".  Including Details here:

NETSCP6 caused an invalid page fault in
module MSVCRT.DLL at 017f:7800d053.
Registers:
EAX=03740848 CS=017f EIP=7800d053 EFLGS=00010246
EBX=00000000 SS=0187 ESP=0068ddcc EBP=0068dde8
ECX=2f504d44 DS=0187 ESI=04577c6c FS=13cf
EDX=000a7c70 ES=0187 EDI=00000014 GS=0000
Bytes at CS:EIP:
8b 14 31 8d 1c 31 89 55 f4 8b 56 fc 89 55 f8 8b 
Stack dump:
04577c70 04577c70 00000000 037431dc 7803704c 78001075 2f504d44 0068de2c 7800cc1c
007a0138 04577c70 04577c70 0452dd24 00000000 7800ef03 7802e248 
Keywords: crash
re-assign to varada.

please investigate this crasher.
Assignee: sspitzer → varada
Component: Mail Window Front End → Composition
Looking into this problem now.
Status: NEW → ASSIGNED
Jon, are you using the PR1 build or are you using an nightly.  I'm using the
6/27 build and couldn't reproduce this.
I'm using the PR1 build.  I'll see if I can repro on the nightly build.
I was able to reproduce the problem on the 06-26-06 trunk build on WinMe-Ja. 
The path (file://) has to appear as a hyperlink, not plain text, in the message
in order for the bug to happen.  When I first tried this on yesterday's build, I
got an error message which I will attach in a moment.  The message says that
there was a problem including the file "file://" in the message, which probably
means that the crash occurs because the hyperlink is being treated as an
attached file.  On every subsequent attempt to send the message, I got a crash
rather than the error message.
I am still unable to reproduce this scenario. Can you attach the message to bug
report.
I've attached the message, but I'm not sure that will help you.  You need to
compose a message with "file://" in the body of the message, then send it to
yourself.  It will send successfully because the "file://" part will not appear
as a hyperlink yet (as I suspect will be the case when you open the attachment).
 When you receive the message, the "file://" part will appear as a hyperlink. 
You can either reply to this message, or copy and paste the hyperlink into a new
message; when you sent, then the crash should occur.  If you still have a
problem reproducing the bug, I can show you here.
I saved the above attached message and copied it to my local folder.
Then I selected the message and did edit as new message and trying to send this 
message resulted in a crash. Sending as plain text, plain text and html, 
just html all three options resulted in a crash.  However, I did not see any 
alert with failing to send seen in first attachment.  Build id: 2001062606 
trunkbuild, and 2001062808 branch build on win98.
Here is the stack trace:  Incident id: 32302301

nsMsgComposeAndSend::HackAttachments 
[d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgSend.cpp, line 2403] 
nsMsgComposeAndSend::Init 
[d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgSend.cpp, line 2749] 
nsMsgComposeAndSend::CreateAndSendMessage 
[d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgSend.cpp, line 3530] 
nsMsgCompose::_SendMsg 
[d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgCompose.cpp, line 671] 
nsMsgCompose::SendMsg 
[d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgCompose.cpp, line 774] 
XPTC_InvokeByIndex 
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp, 
line 139] 
XPCWrappedNative::CallMethod 
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 
1883] 
XPC_WN_CallMethod 
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp, 
line 1253] 
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 809] 
js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2703] 
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 825] 
nsXPCWrappedJSClass::CallMethod 
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp, line 
1002] 
nsXPCWrappedJS::CallMethod 
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp, line 427] 
PrepareAndDispatch 
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp, 
line 102] 
SharedStub 
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp, 
line 124] 
XPTC_InvokeByIndex 
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp, 
line 139] 
XPCWrappedNative::CallMethod 
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 
1883] 
XPC_WN_CallMethod 
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp, 
line 1253] 
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 809] 
js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2703] 
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 825] 
js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 897] 
JS_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3322] 
nsJSContext::CallEventHandler 
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 944] 
nsJSEventListener::HandleEvent 
[d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 140] 
nsEventListenerManager::HandleEventSubType 
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line 
1162] 
nsEventListenerManager::HandleEvent 
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line 
2134] 
nsXULElement::HandleDOMEvent 
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 
3635] 
PresShell::HandleDOMEventWithTarget 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5616] 
nsButtonBoxFrame::MouseClicked 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsButtonBoxFrame.cpp, line 178] 
nsButtonBoxFrame::HandleEvent 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsButtonBoxFrame.cpp, line 128] 
PresShell::HandleEventInternal 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5585] 
PresShell::HandleEventWithTarget 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5540] 
nsEventStateManager::CheckForAndDispatchClick 
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 
2456] 
nsEventStateManager::PostHandleEvent 
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 
1542] 
PresShell::HandleEventInternal 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5589] 
PresShell::HandleEvent 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5495] 
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 377] 
nsViewManager::DispatchEvent 
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2051] 
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 68] 
nsWindow::DispatchEvent 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 724] 
nsWindow::DispatchWindowEvent 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 741] 
nsWindow::DispatchMouseEvent 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4239] 
ChildWindow::DispatchMouseEvent 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4486] 
nsWindow::ProcessMessage 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3233] 
nsWindow::WindowProc 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 989] 
KERNEL32.DLL + 0x363b (0xbff7363b) 
KERNEL32.DLL + 0x24407 (0xbff94407) 
0x00688b5e 
QA Contact: esther → sheelar
nominating this for nsbeta1
Keywords: nsbeta1
I tried this on Mac 2001062806, 2001062904 linux.  Mac crashed while trying to 
send the above attached message. Linux never sends the message. It was stuck at 
the status Attaching.... The message never got sent
This is similar to the security hole that JF is fixing for attaching the img
files in the body of the message. After the fix we would no longer attempt to
treat the file:/// in the body as attachments and 1-wouldnt send them by mistake
2- wouldnt hang trying to attach them 3- wouldnt crash on not finding them in
certain cases.
Marking dup of 88124.

*** This bug has been marked as a duplicate of 88124 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
I don't this this is a valid dup. This bug isn't about a security hole, it's 
about sending a message with an attached file.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
The bug this was marked as a dup of is netscape-confidential, and a summary of
that bug was mentioned in this bug, so making this bug ns-conf.  I'm glad
everyone cc'ed on this bug is at Netscape, because otherwise I might not have
been able to make this bug ns-conf.

Varada: this probably wasn't your fault.  It's *very* easy to miss the fact that
a bug is netscape-confidential.

If this bug needs to be reopened, please file a new, clean bug rather than
reopening this one.
Group: netscapeconfidential?
The reason I marked it dup was because the other bug is going to make sure that
all the cases regarding mistakenly sending files as attachments from the local
machine. This bug was caused by the fact that we were trying to access the
file:/// found in the body of the message as an attachment and that is not
correct behaviour when doing a reply. Similar behaviour is done when the img src
points to the file://. Besides if any embedded object, link, img or anchor is
not send along with the message then it will never go through the route of
leading to the crash. 
sorry didnt see the last comment - should this still be opened as a new bug?
Fix for bug 88124 does not solve this crash. I am able to reproduce it despite I 
have the pach for 88124 in my tree.
Here is a better stack:

_free_dbg_lk(void * 0x08533ba0, int 0x00000001) line 1027 + 26 bytes
_free_dbg(void * 0x08533ba0, int 0x00000001) line 970 + 13 bytes
free(void * 0x08533ba0) line 926 + 11 bytes
PR_Free(void * 0x08533ba0) line 66 + 10 bytes
nsMsgAttachmentHandler::SnarfAttachment(nsMsgCompFields * 0x0852b180) line 551 + 
16 bytes
nsMsgComposeAndSend::HackAttachments(const nsMsgAttachmentData * 0x00000000, 
const nsMsgAttachedFile * 0x00000000) line 2414 + 37 bytes
nsMsgComposeAndSend::Init(nsIMsgIdentity * 0x0609e620, nsMsgCompFields * 
0x07d9cca0, nsFileSpec * 0x00000000, int 0x00000000, int 0x00000000, int 
0x00000000, nsIMsgDBHdr * 0x00000000, const char * 0x01a4ff38, const char * 
0x00000000, unsigned int 0x00000000, const nsMsgAttachmentData * 0x00000000, 
const nsMsgAttachedFile * 0x00000000) line 2760 + 16 bytes
nsMsgComposeAndSend::CreateAndSendMessage(nsMsgComposeAndSend * const 
0x0852b690, nsIEditorShell * 0x07c9c140, nsIMsgIdentity * 0x0609e620, 
nsIMsgCompFields * 0x07d9cca0, int 0x00000000, int 0x00000000, int 0x00000000, 
nsIMsgDBHdr * 0x00000000, const char * 0x01a4ff38, const char * 0x00000000, 
unsigned int 0x00000000, const nsMsgAttachmentData * 0x00000000, ...) line 3541 
+ 54 byte
nsMsgCompose::_SendMsg(int 0x00000000, nsIMsgIdentity * 0x0609e620, int 
0x00000000) line 732 + 203 bytes
nsMsgCompose::SendMsg(nsMsgCompose * const 0x07d9cd60, int 0x00000000, 
nsIMsgIdentity * 0x0609e620, nsIMsgProgress * 0x084f4070) line 837 + 20 bytes
XPTC_InvokeByIndex(nsISupports * 0x07d9cd60, unsigned int 0x00000007, unsigned 
int 0x00000003, nsXPTCVariant * 0x0012be44) line 139
XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode 
CALL_METHOD) line 1881 + 42 bytes
XPC_WN_CallMethod(JSContext * 0x0745f3e0, JSObject * 0x06dd7c18, unsigned int 
0x00000003, long * 0x06e37030, long * 0x0012c078) line 1252 + 11 bytes
[snap]

We are crashing trying to free a string (tempName) which apparently is not a 
valid pointer.
my guess is that GenerateFileNameFromURI(mURL) can return a bag pointer!
ok, I have the fix for the crash:

Index: nsMsgCompUtils.cpp
===================================================================
RCS file: /cvsroot/mozilla/mailnews/compose/src/nsMsgCompUtils.cpp,v
retrieving revision 1.106
diff -u -2 -w -r1.106 nsMsgCompUtils.cpp
--- nsMsgCompUtils.cpp  2001/05/11 21:05:01     1.106
+++ nsMsgCompUtils.cpp  2001/06/29 23:05:48
@@ -1790,5 +1790,5 @@
     char *hostStr = nsMsgParseURLHost(cp2);
     if (!hostStr)
-      hostStr = cp2;
+      hostStr = PL_strdup(cp2);

However, now I hit the alert problem mentionned ealier.
ok, I have the full fix:
Index: src/nsMsgCompUtils.cpp
===================================================================
RCS file: /cvsroot/mozilla/mailnews/compose/src/nsMsgCompUtils.cpp,v
retrieving revision 1.106
diff -u -2 -w -r1.106 nsMsgCompUtils.cpp
--- nsMsgCompUtils.cpp  2001/05/11 21:05:01     1.106
+++ nsMsgCompUtils.cpp  2001/06/29 23:30:33
@@ -1766,4 +1766,6 @@
       }
     }
+    else
+      return nsnull;
   }

@@ -1790,5 +1792,5 @@
     char *hostStr = nsMsgParseURLHost(cp2);
     if (!hostStr)
-      hostStr = cp2;
+      hostStr = PL_strdup(cp2);

     PRBool isHTTP = PR_FALSE;
Keywords: nsbeta1nsBranch
Priority: -- → P1
Target Milestone: --- → mozilla0.9.3
r=varada
reassign the bug to myself.
Assignee: varada → ducarroz
Status: REOPENED → NEW
Whiteboard: have fix
Status: NEW → ASSIGNED
Did this get fixed with the other bug or does this need to go in? If so, can we
get this on the trunk?
Fix for bug 88124 will only avoid to have this situation anymore but it doesn't 
not resolve the problem itself.
sr=mscott
Keywords: nsBranch
moving to 0.9.4
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Is nsScriptSecurityManager::CheckLoadURI involved in this crash at all? 
no
Whiteboard: have fix → have fix, ready to be checked in
Fixed and checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Whiteboard: have fix, ready to be checked in
2001-08-13-06 win98
2001-08-13-06 linux
2001-08-13-04 mac
Using above builds I still unable to send the message that is attached to the 
bug. And also here are the two scenarios that I am doing which is failing to 
send.
On windows:
Scenario 1:  I still have the message attached to this bug in my local folder.  
Using today's build I selected the message from my local folder and clicked on 
edit as new. I typed some text in the message body and click on send.  Sending 
is stalling at attaching the message and did not send.
Scenario 2: Create new message with html compose. From menu item click insert 
link.  Then in the first field "enter text or display for link  I entered 
file://. Then in the next filed choose file I typed file:// again.  Then try 
sending this message resulted in stalling while sending and did not send.  

On Mac it gives me sending message failed error for scenaior 2 
On linux with scenario 2 I could send the message but when I received I had an 
extra link in the message and looked like below:
file:// <cid:part1.070805.01060303@netscape.com as hyperlink.  When I clicked on 
that additional link that got added to the message with only file:// hyperlink 
opened to a new compose window with To:<cid:part1.070805.01060303@netscape.com

I am reopening this bug for the above reasons. But if you think this should be a 
different bug please let me know. But if I should be verifying this in any other 
way sorry about it. Just let me know.  

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Update, another new report.  This time the user received a message from someone
using 4.7 which had an embedded bad link such as this one: 
<p><A HREF="file:///F|/publish/My">file:///F|/publish/My</A>
pages/tables/pages.html</html>  This html was also sent as an attachment so it
was viewable when the message was read by the user.  When the Mac user tried to
forward the message, he received the failure to send error with no explaination.
 As Sheela reports, trying to forward this type of message with windows will
just continue trying to send with no error. 





Adding ns enterprise nomination. 
Keywords: nsenterprise
JF is on vacation until after .9.4 is out the door so I'll take this as I'm
trying to fix his .9.4 bugs. 

It appears that the remaining problem occurs when you are sending a message and
you've added file urls that don't exist. That's why Sheila can reproduce the
problem  when she attempts to edit the message as new and send it again. JF
fixed the forward case when he fixed the security hole in  88124. 

In my fix, I'm trying to make us skip any attachments which are local files
which don't exist. However, I'm wondering why we fetch the urls at all. Just
because I send a message and I type file://fooo doesn't mean we should fetch the
file as part of the message. For new messages we don't attempt to fetch it.
Seems like we only get into trouble when we are attempting to send a message
where the file url has been linkified......

One possibly easy fix (if we really don't want to fetch linkified file:// urls
when sending an old message as new) is to modify
nsMsgComposeAndSend::ProcessMultipartRelated which examines all the link dom
elements in the message body to figure out what attachments need fetched. We
could step in here and see if the anchor is a file url and if it is, skip it. 

This later solution assumes we'd all agree that the default behavior  would be
to never fetch a file url if it's an anchor even when it's a new message
Assignee: ducarroz → mscott
Status: REOPENED → NEW
Attached patch possible fix (obsolete) — Splinter Review
Okay the patch I have to this bug implements the second solution I described
above. When generating the list of urls we need to fetch, if we find a dom
anchor in the body and the anchor refers to a file url, we skip it and don't try
to fetch it. Am I being ignorant here and is this going to turn around and break
a common way of sending local files from your machine to someone else?
Maybe...I'm not too familiar with this code. 

I suppose I could be more specific and test if the anchor element refers to a
file url which doesnt't exist. If that's the case then don't try to fetch it. 
I wonder if not fetching local URL might break AppleDouble on Mac! Can you try
to setup a link to a local binary file (an executable would be the pefect test)
and see if when you receive the message you are still able to run it.
JF! working on your vacation again =). I don't think it should effect apple
double because we only abort the fetch if it's a file url anchor inside of a
document. 

So I'd have to send a message where instead of attaching a binary file, I
instead created an anchor in my compose window:

<a href="file://somefoo.exe">Binary File</a>

or does apple double substitue anchors like this into the message?
I don't know but all I remember is that for some wierd reason, we fetch, on Mac
only, loacal attachment in order to make the AppleDouble encoding works!
Okay, I just verified that my patch doen't break the ability to send page for a
file url. i.e. load a local file in the brower, click send page. We still fetch
the filie and send it. The code I modified isn't executed on external
attachments to the message. So we won't effect apple double either. 
JF, I know you are on vacation, but I wouldn't feel comfortable checking this
patch in unless you signed off on it. Any chance of a review? =)
Sorry If I did not fully understood the problem earlier. I don?t really like
your patch for the following reason:

1) Having anchor with a local file without sending the file is not good. That
doesn?t make sense as the recipient will be missing the file and therefore won?t
be able to use the anchor.

2) Your fix doesn?t solve similarly problem with bogus image or link url.

I have another solution that consists to check if a local url point to an
existing file and if not, we skip it. This for all kind of embedded object we
support. I am posting the patch right now?
Attached patch Proposed fix, V2 (obsolete) — Splinter Review
Why does sending mail fetch hyperlinked documents in the first place?  Inline 
images I can understand, but why linked documents?
If user A put a link to a local document into an email and send it to user B, user B should be able to click on this link 
and get the document. This would work only if we transmit the document as well with the email message. Else the 
link would be dead as the receiver will probably don't have the same document installed at the same location in his 
own computer. When we send the link, the URL is modified to point into the related part insinde the email message 
instead of the local file.

Let's imagine you are a is person and want the people on your network to install a program. You want to make this 
install as easy as possible. You can write an email that say: "Click here to intall the program". Don't need for the 
user to save the attachment and then execute it! Juste need to point and click.

Try to send you a document like that, you will see it could be convient.
Do we also scan to see if the document links to other documents or includes 
images?
So are you telling me that if I have the text
file:////u/bbaetz/someLarge100MegInstallFile in my mail then we will attach it
to the message silently? And that that is expected behaviour?

See the comment by varada@netscape.com at 2001-06-29 14:37, and the bug that
this was marked a dupe of.

If you want to have some way to have a hyperlink to an attachment which is
explictly added by the user, then thats one thing. And obviously "send page" on
a file url should send that page. However, silently attaching file urls which
are mentioned somewhere in the body of the message is Bad.

In fact, I can't (with 0.9.3) get a file link to be automatically attached.
Whenever I try, the link is translated into something like
<cid:part1.00020300.08090801@netscape.com>. Can someone give me instructions on
how to have a file automatically attached, or (preferably) tell me that I'm
misunderstanding this?
>Do we also scan to see if the document links to other documents or includes 
>images?

No, we stop at the first level. We fetch only object you have specified yourself.
The comment from Varada which was in fact about the original problem was that we were fetching links that came 
from a message you are replying to. We are not doing that anymore for obvious security reason. The only object we 
are now fetching is the one you have added yourself to the message body.
this work will happen during .9.5 but is still scheduled to land on the branch.
Keywords: nsbranch+
Target Milestone: mozilla0.9.4 → mozilla0.9.5
load balancing back to JF to drive the right fix (which ever that is) into the
trunk and branch).
Assignee: mscott → ducarroz
Status: NEW → ASSIGNED
Whiteboard: have fix
Comment on attachment 47064 [details] [diff] [review]
Proposed fix, V2

r=varada
Attachment #47064 - Flags: review+
Attachment #46855 - Attachment is obsolete: true
if you changed that boolean to "isAValidFile", the code would be cleaner, and
easier to read.
Attached patch proposed fix, v3Splinter Review
Attachment #47064 - Attachment is obsolete: true
Attachment #50023 - Flags: superreview+
Attachment #50023 - Flags: review+
Fixed in the trunk, waiting PDT approval for the branch
Blocks: 99508
Whiteboard: have fix → Fixed in the trunk
JF - what areas should we test around for your fix?
here are what to test:

1) Security:

-Send yourself a webpage (www.netscape.com) which contains links
-Forward inline the message or reply to it to yourself
-Get the (forwarded) message and look at the source, it should not contains the
source data for any of the original embedded objects (images)

2) Embebbed object
- create an HTML message, add an inline image and add an inline local file
(insert link)
- send the message to *another* machine and check if you can click on the link
to the local file and see the data, should work. Also you should see the image.

3) Bad Embedded object
- create an HTML message, add an inline image and insert a link with an invalid
file path.
-Send the message. Should work.
fixing group.
assignee_accessible: 0 → 1
Group: netscapeconfidential? → security?
CC list accessible: true
qacontact_accessible: 0 → 1
Accessible to reporter
This was marked PDT+ at the meeting today. One interesting test scenario came up
at the meeting. kmurray says he was able to reproduce this bug by just typing in
"file:" in the body of a compose window. Try that test scenario before and after. 
Whiteboard: Fixed in the trunk → Fixed in the trunk, PDT+
Fixed in the branch too.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Whiteboard: Fixed in the trunk, PDT+ → PDT+
Verified using branch build from 2001-10-17-18.
I tested all the scenarios mentioned by JFD in his comments from 2001-09-20 09:57 
Also tested both the scenarios that I mentioned in my comments:2001-08-13 15:41.

I still need to verify this on the trunk build adding keyword vtrunk. 
Keywords: vtrunk
Forgot to mention the platforms
branch build: 2001-10-17-18 on win98, mac OS X, linux RH 6.2
Removing vtrunk since this is now verified on trunk as well.
build: 2001-11-09-06 win98, mac os 9.1, linux
On linux was unable to test due to probably a regression bug. When I send page 
from browser, receive this in mail and try to forward online the message compose 
never comes up.  See bug 109412
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Group: security?
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: