Closed
Bug 88079
Opened 23 years ago
Closed 23 years ago
Cannot send message that contains file:// hyperlink
Categories
(MailNews Core :: Composition, defect, P1)
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)
9.46 KB,
image/jpeg
|
Details | |
6.24 KB,
application/octet-stream
|
Details | |
1.17 KB,
patch
|
vparthas
:
review+
Bienvenu
:
superreview+
|
Details | Diff | Splinter Review |
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
Comment 2•23 years ago
|
||
re-assign to varada. please investigate this crasher.
Assignee: sspitzer → varada
Component: Mail Window Front End → Composition
Comment 4•23 years ago
|
||
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.
Reporter | ||
Comment 10•23 years ago
|
||
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.
Comment 11•23 years ago
|
||
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
Comment 13•23 years ago
|
||
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
Comment 14•23 years ago
|
||
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
Comment 15•23 years ago
|
||
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 → ---
Comment 16•23 years ago
|
||
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.
Updated•23 years ago
|
Group: netscapeconfidential?
Comment 17•23 years ago
|
||
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.
Comment 18•23 years ago
|
||
sorry didnt see the last comment - should this still be opened as a new bug?
Assignee | ||
Comment 19•23 years ago
|
||
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.
Assignee | ||
Comment 20•23 years ago
|
||
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.
Assignee | ||
Comment 21•23 years ago
|
||
my guess is that GenerateFileNameFromURI(mURL) can return a bag pointer!
Assignee | ||
Comment 22•23 years ago
|
||
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.
Assignee | ||
Comment 23•23 years ago
|
||
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;
Updated•23 years ago
|
Comment 24•23 years ago
|
||
r=varada
Assignee | ||
Comment 25•23 years ago
|
||
reassign the bug to myself.
Assignee: varada → ducarroz
Status: REOPENED → NEW
Whiteboard: have fix
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Comment 26•23 years ago
|
||
Did this get fixed with the other bug or does this need to go in? If so, can we get this on the trunk?
Assignee | ||
Comment 27•23 years ago
|
||
Fix for bug 88124 will only avoid to have this situation anymore but it doesn't not resolve the problem itself.
Comment 28•23 years ago
|
||
sr=mscott
Comment 30•23 years ago
|
||
Is nsScriptSecurityManager::CheckLoadURI involved in this crash at all?
Assignee | ||
Comment 31•23 years ago
|
||
no
Assignee | ||
Updated•23 years ago
|
Whiteboard: have fix → have fix, ready to be checked in
Assignee | ||
Comment 32•23 years ago
|
||
Fixed and checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Whiteboard: have fix, ready to be checked in
Comment 33•23 years ago
|
||
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 → ---
Comment 34•23 years ago
|
||
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.
Comment 36•23 years ago
|
||
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
Comment 37•23 years ago
|
||
Comment 38•23 years ago
|
||
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.
Assignee | ||
Comment 39•23 years ago
|
||
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.
Comment 40•23 years ago
|
||
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?
Assignee | ||
Comment 41•23 years ago
|
||
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!
Comment 42•23 years ago
|
||
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.
Comment 43•23 years ago
|
||
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? =)
Assignee | ||
Comment 44•23 years ago
|
||
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?
Assignee | ||
Comment 45•23 years ago
|
||
Comment 46•23 years ago
|
||
Why does sending mail fetch hyperlinked documents in the first place? Inline images I can understand, but why linked documents?
Assignee | ||
Comment 47•23 years ago
|
||
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.
Comment 48•23 years ago
|
||
Do we also scan to see if the document links to other documents or includes images?
Comment 49•23 years ago
|
||
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?
Assignee | ||
Comment 50•23 years ago
|
||
>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.
Assignee | ||
Comment 51•23 years ago
|
||
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.
Comment 52•23 years ago
|
||
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
Comment 53•23 years ago
|
||
load balancing back to JF to drive the right fix (which ever that is) into the trunk and branch).
Assignee: mscott → ducarroz
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Whiteboard: have fix
Comment 54•23 years ago
|
||
Comment on attachment 47064 [details] [diff] [review] Proposed fix, V2 r=varada
Attachment #47064 -
Flags: review+
Assignee | ||
Updated•23 years ago
|
Attachment #46855 -
Attachment is obsolete: true
Comment 55•23 years ago
|
||
if you changed that boolean to "isAValidFile", the code would be cleaner, and easier to read.
Assignee | ||
Comment 56•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Attachment #47064 -
Attachment is obsolete: true
Updated•23 years ago
|
Attachment #50023 -
Flags: superreview+
Attachment #50023 -
Flags: review+
Assignee | ||
Comment 57•23 years ago
|
||
Fixed in the trunk, waiting PDT approval for the branch
Blocks: 99508
Whiteboard: have fix → Fixed in the trunk
Comment 58•23 years ago
|
||
JF - what areas should we test around for your fix?
Assignee | ||
Comment 59•23 years ago
|
||
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.
Comment 60•23 years ago
|
||
fixing group.
assignee_accessible: 0 → 1
Group: netscapeconfidential? → security?
CC list accessible: true
qacontact_accessible: 0 → 1
Accessible to reporter
Comment 61•23 years ago
|
||
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+
Assignee | ||
Comment 62•23 years ago
|
||
Fixed in the branch too.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Whiteboard: Fixed in the trunk, PDT+ → PDT+
Comment 63•23 years ago
|
||
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
Comment 64•23 years ago
|
||
Forgot to mention the platforms branch build: 2001-10-17-18 on win98, mac OS X, linux RH 6.2
Comment 65•23 years ago
|
||
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
Updated•22 years ago
|
Group: security?
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•