I'm not sure if this is the same bug that we already know about, but in today's build if I click on a message in the 3pane that has the URL listed above as an attachment, it dies in PICS code at: nsPICS::OnEndURLLoad(nsPICS * const 0x01010e24, nsIDocumentLoader * 0x03e451d0, nsIURL * 0x03e46c80, int 0) line 895 + 3 bytes nsDocLoaderImpl::FireOnEndURLLoad(nsIDocumentLoader * 0x03e451d0, nsIURL * 0x03e46c80, int 0) line 942 nsDocLoaderImpl::FireOnEndURLLoad(nsIDocumentLoader * 0x03e451d0, nsIURL * 0x03e46c80, int 0) line 950 nsDocLoaderImpl::FireOnEndURLLoad(nsIDocumentLoader * 0x03e451d0, nsIURL * 0x03e46c80, int 0) line 950 nsDocLoaderImpl::FireOnEndURLLoad(nsIDocumentLoader * 0x03e451d0, nsIURL * 0x03e46c80, int 0) line 950 nsDocLoaderImpl::FireOnEndURLLoad(nsIDocumentLoader * 0x03e451d0, nsIURL * 0x03e46c80, int 0) line 950 nsDocLoaderImpl::FireOnEndURLLoad(nsIDocumentLoader * 0x03e451d0, nsIURL * 0x03e46c80, int 0) line 950 nsDocLoaderImpl::LoadURLComplete(nsIURL * 0x03e46c80, nsISupports * 0x03e46d40, int 0) line 1003 nsDocumentBindInfo::OnStopBinding(nsDocumentBindInfo * const 0x03e46d40, nsIURL * 0x03e46c80, unsigned int 0, const unsigned short * 0x03e64770) line 1536 OnStopBindingProxyEvent::HandleEvent(OnStopBindingProxyEvent * const 0x03e65940) line 592 + 45 bytes StreamListenerProxyEvent::HandlePLEvent(PLEvent * 0x03e65944) line 472 + 12 bytes PL_HandleEvent(PLEvent * 0x03e65944) line 476 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x010114d0) line 437 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00030c62, unsigned int 49359, unsigned int 0, long 16848080) line 799 + 9 bytes USER32! 77e71250() 010114d0() where urlData is NULL when it tries to access it. This page works fine in the browser.

This may be the same bug we were talking about on mailnews staff the other day. But we didn't file a bug on it. The ownership document refers to a stylse sheet using a relative path. When we are displaying the message, we're running a file url which points to a temp file containing the message. So the layout engine is resolving the relative path for the style sheet against the file url we're running. of course there is no style sheet in the directory of the temp message we are trying to display and we crash. On linux the crash happens much earlier than this stack trace and you can clearly see that it is crashing trying to load the style sheet for the document. This stack trace on windows looks very different though so maybe it isn't the same problem. Any ideas neeti? If my theory is correct, then there's nothing we can do about this bug until we have pluggable stream converters from necko which is targeted for M9 I think. That's when we'd remove our write the msg to a file hack...Setting milestone to M9.

This is a PICS bug. I am fixing it.

Information on how to set up mail can be found at http://www.mozilla.org/mailnews/smoketest.html You can use 4.x to send yourself this page and then use 5.0's GetMsgs to download it.

This now works for me.

Verified on Win32 using the May 11 build id 1999051108 - no May 12 build avail. Verified on Linux using the May 11 build id 1999051108 and May 12 (19899051209) Crash using the Mac May 11 build id 1999051108. Incident ID 8508681 and 8508668 It also crash in the Mac May 12 build id 1999051210 but could not generate talkback info because commercial build was not available. Re-open bug and updating summary to add [PP] Steps to reproduce problem 1) From Communicator, open a browser window 2) Go to URL - http://www.mozilla.org/projects/xpcom/Ownership.html 3) Send this page to yourself Note: because of bug 6016, you can not retrieve mail directly in Seamonkey 4) Retrieve the mail message in Communicator 5) View message to ensure it has it file attachment 6 [details]) Copy the message to a local mail box 7) Exit Communicator 8) Copy this mail box to your Seamonkey mail folder 9) Start Seamonkey 10) Open Messenger from the task bar 11) Double click on the mail server to expand folder 12) Select your folder 13) Select the message that has this web attachment Crash to Macsbug Here is the Talkback call stack 8508681. The call stacks are similar. Call Stack: (Signature = 0x48000008 401e4bdf) 0x48000008 layout.shlb + 0x348c0 (0x062114e0) layout.shlb + 0x34d88 (0x062119a8) layout.shlb + 0x33048 (0x0620fc68) CNavDTD::AddLeaf() [CNavDTD.cpp, line 2733] CNavDTD::AddHeadLeaf() [CNavDTD.cpp, line 2763] CNavDTD::HandleStartToken() [CNavDTD.cpp, line 1283] NavDispatchTokenHandler() [CNavDTD.cpp, line 249] .__cl__13CTokenHandlerFP6CTokenP6nsIDTD [nsTokenHandler.cpp, line 80] CNavDTD::HandleToken() [CNavDTD.cpp, line 629] CNavDTD::BuildModel() [CNavDTD.cpp, line 510] nsParser::BuildModel() [nsParser.cpp, line 886] nsParser::ResumeParse() [nsParser.cpp, line 838] nsParser::OnDataAvailable() [nsParser.cpp, line 1050] nsDocumentBindInfo::OnDataAvailable() [nsDocLoader.cpp, line 1498] stub_put_block() [nsStubContext.cpp, line 833] nsNetConverterStream::Write() [nsNetConverterStream.cpp, line 137] htmlEmitter.shlb + 0x2200 (0x069c55e0)

Clearing resolution

On windows, this bug was crashing in pics.dll. PICS is not enabled on the mac.There is no pics.dll on mac. So, I am not sure if this is same bug as it was on windows. On windows, it was crashing inside pics code. Here, it looks like it crashes within the parser code. I am cc Harish Dhurvasula on this bug.

After speaking to Neeti, I have logged new bug 6699. I can not reproduce this crash on Win32 or Linux. It looks like a Mac-only bug. Neeti, if you resolve the bug as fixed, I will verify this bug. /Peter

Verified as fixed using the Win32 and Linux May 18 Seamonkey build (1999051809)