Closed Bug 76200 Opened 24 years ago Closed 24 years ago

Mail crashes after opening HTML message with corrupted img field (very long ALT and no SRC)

Categories

(MailNews Core :: Backend, defect, P2)

Product:
MailNews Core
Component:
Backend
Platform:
x86
Windows ME
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: piskozub, Assigned: sspitzer)

References

Details

(Keywords: regression, Whiteboard: [nsbeta1+])

Attachments

(4 files)

The text of the message crashing Mozilla
858 bytes, text/html
Details
additional null checks for mImageRequest
3.12 KB, patch
Details | Diff | Splinter Review
fix to allow mScheme to be null
584 bytes, patch
Details | Diff | Splinter Review
fixing the caller, please review
1.02 KB, patch
Details | Diff | Splinter Review
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.8.1+) Gecko/20010416 BuildID: 2001041604 Today Win32 installer build crashes on a messagge with all the text as a very long IMG ALT field with no actual SRC in the field. I'll attach the culprit HTML. This is a recent regression, I read and deleted this piece of SPAM with 20010411 morning build with no problem Reproducible: Always Steps to Reproduce: 1. Send this attached crap to yourself 2. Try to read the message 3. Crash Actual Results: Crash (after marking the message as read) Expected Results: Message opens showing anythng (the message is actually empty except for the long IMG ALT field. I mart this critical as this may lead to a very simple Denial of Service attack
Keywords: regression
More comment: Today build 20010416 crashes with an exception in necko.dll. The above mentioned 20010411 crashed today on the message with gklayout.dll error (however I am sure I read this message earlier with that build on another host). Mozilla 0.8.1 does not crash showing an empty message (pretty reasonable) while Netscape 4.77 shows the broken image icon with all the ALT text as one long line (correct but not necessary reasonable). This means that: - this is the new MailNews branch error - something in the last four days made it even worse (crash every time, instead of intermittant)
-> Composition Oh, and BTW, I don't think this is related to the MailNews branch since that didn't change Composition/Viewing of messages as far as I know.
Component: Mail Window Front End → Composition
You may be right but this HTML shows OK in a browser window. Therefore I assumed (maybe wrong) that it has something to do with MailNews and as Mozilla 0.8.1 does not have it, the new branch seemed the best usual suspect.
Since this is composer/HTML-renderer, maybe Editor has something to do with it? CC beppe and brade
accepting. it's a mail backend problem. excellent bug report, Jacek
Status: UNCONFIRMED → ASSIGNED
Component: Composition → Mail Back End
Ever confirmed: true
here's the stack the crasher is because mScheme is null. nsStdURL::SchemeIs(nsStdURL * const 0x08acf900, const char * 0x025e29c8, int * 0x0012ed4c) line 312 + 12 bytes nsMsgMailNewsUrl::SchemeIs(nsMsgMailNewsUrl * const 0x08acf984, const char * 0x025e29c8, int * 0x0012ed4c) line 486 GetCacheSession(nsIURI * 0x08acf984, nsICacheSession * * 0x0012ed9c) line 82 imgCache::Get(nsIURI * 0x08acf984, imgRequest * * 0x0012ef3c, nsICacheEntryDescriptor * * 0x0012eed4) line 183 + 33 bytes imgLoader::LoadImage(imgLoader * const 0x025ae920, nsIURI * 0x08acf984, nsILoadGroup * 0x06bb5db0, imgIDecoderObserver * 0x08aceca0, nsISupports * 0x066bbb70, imgIRequest * * 0x072e4fb4) line 78 + 40 bytes nsImageFrame::Init(nsImageFrame * const 0x072e4f20, nsIPresContext * 0x066bbb70, nsIContent * 0x08a41500, nsIFrame * 0x072e4e48, nsIStyleContext * 0x08acd6f0, nsIFrame * 0x00000000) line 291 + 111 bytes nsCSSFrameConstructor::InitAndRestoreFrame(nsIPresContext * 0x066bbb70, nsFrameConstructorState & {...}, nsIContent * 0x08a41500, nsIFrame * 0x072e4e48, nsIStyleContext * 0x08acd6f0, nsIFrame * 0x00000000, nsIFrame * 0x072e4f20) line 6663 + 32 bytes nsCSSFrameConstructor::ConstructFrameByTag(nsIPresShell * 0x066ae490, nsIPresContext * 0x066bbb70, nsFrameConstructorState & {...}, nsIContent * 0x08a41500, nsIFrame * 0x072e4e48, nsIAtom * 0x0173df40 {"img"}, int 3, nsIStyleContext * 0x08acd6f0, nsFrameItems & {...}) line 4926 nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x066ae490, nsIPresContext * 0x066bbb70, nsFrameConstructorState & {...}, nsIContent * 0x08a41500, nsIFrame * 0x072e4e48, nsIAtom * 0x0173df40 {"img"}, int 3, nsIStyleContext * 0x08acd6f0, nsFrameItems & {...}, int 0) line 7181 + 52 bytes nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x066ae490, nsIPresContext * 0x066bbb70, nsFrameConstructorState & {...}, nsIContent * 0x08a41500, nsIFrame * 0x072e4e48, nsFrameItems & {...}) line 7091 + 56 bytes nsCSSFrameConstructor::ContentAppended(nsCSSFrameConstructor * const 0x066a8460, nsIPresContext * 0x066bbb70, nsIContent * 0x06bcac00, int 0) line 8083 StyleSetImpl::ContentAppended(StyleSetImpl * const 0x066a8520, nsIPresContext * 0x066bbb70, nsIContent * 0x06bcac00, int 0) line 1241 PresShell::ContentAppended(PresShell * const 0x066ae498, nsIDocument * 0x089ae6d0, nsIContent * 0x06bcac00, int 0) line 4534 + 46 bytes nsDocument::ContentAppended(nsDocument * const 0x089ae6d0, nsIContent * 0x06bcac00, int 0) line 1537 nsHTMLDocument::ContentAppended(nsHTMLDocument * const 0x089ae6d0, nsIContent * 0x06bcac00, int 0) line 1281 + 17 bytes HTMLContentSink::NotifyAppend(nsIContent * 0x06bcac00, int 0) line 4574 SinkContext::FlushTags(int 1) line 2046 HTMLContentSink::CloseBody(HTMLContentSink * const 0x066eceb0, const nsIParserNode & {...}) line 2902 CNavDTD::CloseBody(const nsIParserNode * 0x071fc4b8) line 3134 + 31 bytes CNavDTD::CloseContainer(const nsCParserNode * 0x071fc4b8, nsHTMLTag eHTMLTag_body, int 0) line 3532 + 12 bytes CNavDTD::CloseContainersTo(int 1, nsHTMLTag eHTMLTag_body, int 0) line 3593 + 20 bytes CNavDTD::CloseContainersTo(nsHTMLTag eHTMLTag_body, int 0) line 3750 + 20 bytes CNavDTD::DidBuildModel(CNavDTD * const 0x06b8d9f0, unsigned int 0, int 1, nsIParser * 0x089af3f0, nsIContentSink * 0x066eceb0) line 579 nsParser::DidBuildModel(unsigned int 0) line 1419 + 60 bytes nsParser::ResumeParse(int 1, int 1) line 1958 nsParser::OnStopRequest(nsParser * const 0x089af3f8, nsIRequest * 0x089a1094, nsISupports * 0x0557eea0, unsigned int 0) line 2399 + 19 bytes nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x089ad3f0, nsIRequest * 0x089a1094, nsISupports * 0x0557eea0, unsigned int 0) line 277 nsStreamConverter::OnStopRequest(nsStreamConverter * const 0x089ad340, nsIRequest * 0x089a1094, nsISupports * 0x0557eea0, unsigned int 0) line 1013 nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x089a2cb0, nsIRequest * 0x089a1094, nsISupports * 0x0557eea0, unsigned int 0) line 277 nsMsgProtocol::OnStopRequest(nsMsgProtocol * const 0x089a1090, nsIRequest * 0x089a2884, nsISupports * 0x0557eea0, unsigned int 0) line 271 + 88 bytes nsMailboxProtocol::OnStopRequest(nsMailboxProtocol * const 0x089a1090, nsIRequest * 0x089a2884, nsISupports * 0x0557eea0, unsigned int 0) line 204 nsOnStopRequestEvent::HandleEvent() line 159 nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x089a20c4) line 64 PL_HandleEvent(PLEvent * 0x089a20c4) line 588 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00a0a990) line 518 + 9 bytes _md_EventReceiverProc(HWND__ * 0x0047069e, unsigned int 49422, unsigned int 0, long 10529168) line 1069 + 9 bytes USER32! 77e71820
Seth, I can fix it if it's just a matter of bullet-proofing..?
Keywords: nsbeta1
Priority: -- → P2
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.9
the lack of the src attribute (I bet the same thing would happen if we had src="") on the image gets eventually gets us to the point where nsScriptSecurityManager::GetCodebasePrincipal() calls NS_NewURI() with "mailbox://" line 821, nsScriptSecurityManager.cpp: rv = NS_NewURI(getter_AddRefs(newURI), originUrl, nsnull) I think this might be a parser bug. we could fix necko or mailnews to not crash in the mailbox:// case, but I think something bigger is broken. mstoltz / harishd / mscott, any comments?
harishd, see #66673 I think it is related.
I take that back. I was looking at the wrong thing. "mailbox://" is ok, the problem comes from nsImageFrame::Init() calling NS_NewURI() with "". it may still be parser related, I don't know enough about this. here's the stack that includes that call to NS_NewURI() nsMsgMailNewsUrl::nsMsgMailNewsUrl() line 46 nsMailboxUrl::nsMailboxUrl() line 129 + 27 bytes nsMailboxUrlConstructor(nsISupports * 0x00000000, const nsID & {...}, void * * 0x0012ee9c) line 49 + 87 bytes nsGenericFactory::CreateInstance(nsGenericFactory * const 0x066b20f0, nsISupports * 0x00000000, const nsID & {...}, void * * 0x0012ee9c) line 56 nsComponentManagerImpl::CreateInstance(nsComponentManagerImpl * const 0x009552f0, const nsID & {...}, nsISupports * 0x00000000, const nsID & {...}, void * * 0x0012ee9c) line 1199 + 24 bytes nsComponentManager::CreateInstance(const nsID & {...}, nsISupports * 0x00000000, const nsID & {...}, void * * 0x0012ee9c) line 82 nsMailboxService::NewURI(nsMailboxService * const 0x066b3e6c, const char * 0x04e5a030, nsIURI * 0x066c8bc4, nsIURI * * 0x0012f064) line 399 + 43 bytes nsIOService::NewURI(const char * 0x04e5a030, nsIURI * 0x066c8bc4, nsIURI * * 0x0012f064, nsIProtocolHandler * * 0x00000000) line 288 + 35 bytes nsIOService::NewURI(nsIOService * const 0x0181bb80, const char * 0x04e5a030, nsIURI * 0x066c8bc4, nsIURI * * 0x0012f064) line 296 NS_NewURI(nsIURI * * 0x0012f064, const char * 0x04e5a030, nsIURI * 0x066c8bc4, nsIIOService * 0x0181bb80) line 77 + 24 bytes NS_NewURI(nsIURI * * 0x0012f064, const nsAString & {...}, nsIURI * 0x066c8bc4, nsIIOService * 0x00000000) line 89 + 21 bytes nsImageFrame::Init(nsImageFrame * const 0x0128bf48, nsIPresContext * 0x064e41f0, nsIContent * 0x04e5a060, nsIFrame * 0x013002d8, nsIStyleContext * 0x04e5a760, nsIFrame * 0x00000000) line 290 + 56 bytes nsCSSFrameConstructor::InitAndRestoreFrame(nsIPresContext * 0x064e41f0, nsFrameConstructorState & {...}, nsIContent * 0x04e5a060, nsIFrame * 0x013002d8, nsIStyleContext * 0x04e5a760, nsIFrame * 0x00000000, nsIFrame * 0x0128bf48) line 6663 + 32 bytes nsCSSFrameConstructor::ConstructFrameByTag(nsIPresShell * 0x065120f0, nsIPresContext * 0x064e41f0, nsFrameConstructorState & {...}, nsIContent * 0x04e5a060, nsIFrame * 0x013002d8, nsIAtom * 0x0184c140 {"img"}, int 3, nsIStyleContext * 0x04e5a760, nsFrameItems & {...}) line 4926 nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x065120f0, nsIPresContext * 0x064e41f0, nsFrameConstructorState & {...}, nsIContent * 0x04e5a060, nsIFrame * 0x013002d8, nsIAtom * 0x0184c140 {"img"}, int 3, nsIStyleContext * 0x04e5a760, nsFrameItems & {...}, int 0) line 7181 + 52 bytes nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x065120f0, nsIPresContext * 0x064e41f0, nsFrameConstructorState & {...}, nsIContent * 0x04e5a060, nsIFrame * 0x013002d8, nsFrameItems & {...}) line 7091 + 56 bytes nsCSSFrameConstructor::ContentAppended(nsCSSFrameConstructor * const 0x06512480, nsIPresContext * 0x064e41f0, nsIContent * 0x06519c50, int 1) line 8083 StyleSetImpl::ContentAppended(StyleSetImpl * const 0x065133c0, nsIPresContext * 0x064e41f0, nsIContent * 0x06519c50, int 1) line 1241 PresShell::ContentAppended(PresShell * const 0x065120f8, nsIDocument * 0x066d2ce0, nsIContent * 0x06519c50, int 1) line 4534 + 46 bytes nsDocument::ContentAppended(nsDocument * const 0x066d2ce0, nsIContent * 0x06519c50, int 1) line 1537 nsHTMLDocument::ContentAppended(nsHTMLDocument * const 0x066d2ce0, nsIContent * 0x06519c50, int 1) line 1281 + 17 bytes HTMLContentSink::NotifyAppend(nsIContent * 0x06519c50, int 1) line 4574 SinkContext::FlushTags(int 1) line 2046 HTMLContentSink::CloseBody(HTMLContentSink * const 0x066d3150, const nsIParserNode & {...}) line 2902 CNavDTD::CloseBody(const nsIParserNode * 0x0122a0f0) line 3134 + 31 bytes CNavDTD::CloseContainer(const nsCParserNode * 0x0122a0f0, nsHTMLTag eHTMLTag_body, int 0) line 3532 + 12 bytes CNavDTD::CloseContainersTo(int 1, nsHTMLTag eHTMLTag_body, int 0) line 3593 + 20 bytes CNavDTD::CloseContainersTo(nsHTMLTag eHTMLTag_body, int 0) line 3750 + 20 bytes CNavDTD::DidBuildModel(CNavDTD * const 0x0651ee40, unsigned int 0, int 1, nsIParser * 0x066d39b0, nsIContentSink * 0x066d3150) line 579 nsParser::DidBuildModel(unsigned int 0) line 1419 + 60 bytes nsParser::ResumeParse(int 1, int 1) line 1958 nsParser::OnStopRequest(nsParser * const 0x066d39b8, nsIRequest * 0x066c8504, nsISupports * 0x066c8bc0, unsigned int 0) line 2399 + 19 bytes nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x066d1af0, nsIRequest * 0x066c8504, nsISupports * 0x066c8bc0, unsigned int 0) line 277 nsStreamConverter::OnStopRequest(nsStreamConverter * const 0x066d1a40, nsIRequest * 0x066c8504, nsISupports * 0x066c8bc0, unsigned int 0) line 1013 nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x066c9fb0, nsIRequest * 0x066c8504, nsISupports * 0x066c8bc0, unsigned int 0) line 277 nsMsgProtocol::OnStopRequest(nsMsgProtocol * const 0x066c8500, nsIRequest * 0x066c8d54, nsISupports * 0x066c8bc0, unsigned int 0) line 271 + 88 bytes nsMailboxProtocol::OnStopRequest(nsMailboxProtocol * const 0x066c8500, nsIRequest * 0x066c8d54, nsISupports * 0x066c8bc0, unsigned int 0) line 204 nsOnStopRequestEvent::HandleEvent() line 159 nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x066ccc04) line 64 PL_HandleEvent(PLEvent * 0x066ccc04) line 588 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00a0a990) line 518 + 9 bytes _md_EventReceiverProc(HWND__ * 0x10bb0116, unsigned int 49422, unsigned int 0, long 10529168) line 1069 + 9 bytes USER32! 77e71820() 00a0a990()
I think we need some layout help on this one. (cc'ing pavlov, since it is img related) 1) it looks like in the general case we don't display the internal "broken image" gif. is there a bug on that? 2) <img> without a src attribute or src="" should show the broken image gif. Where would that happen? Can this check happen at nsImageFrame.cpp? something like: Index: html/base/src/nsImageFrame.cpp =================================================================== RCS file: /cvsroot/mozilla/layout/html/base/src/nsImageFrame.cpp,v retrieving revision 1.161 diff -u -w -r1.161 nsImageFrame.cpp --- nsImageFrame.cpp 2001/04/11 08:12:10 1.161 +++ nsImageFrame.cpp 2001/04/16 22:50:16 @@ -287,6 +287,12 @@ mCanSendLoadEvent = PR_TRUE; nsCOMPtr<nsIURI> srcURI; + + // if src == "", there is nothing to load + if (src.Length() == 0) { + src = NS_LITERAL_STRING("chrome://communicator/skin/broken.gif").get() ; + } + NS_NewURI(getter_AddRefs(srcURI), src, baseURL); il->LoadImage(srcURI, loadGroup, mListener, aPresContext, getter_AddRefs(mIma geRequest)); // if the image was found in the cache, it is possible that LoadImage will re sult in a call to OnStartContainer()
if the source is broken, then it should fall through just like broken images and get replaced by the alt text. we shouldn't special case url in the image frame, and we certainly shouldn't have a hardcoded chrome:// image in there.
i have to be able to call NewURI with "" since the baseurl should be merged in with it (and i suppose the base url could be an image url...)
bug 72447 is also due to SchemeIs crashing when mScheme is null. I think we need to fix this in necko to say the scheme isn't whatever since the scheme is null (i suppose unless you pass in a null scheme.. heh)
pavlov: what do we show if there isn't any alt text? do we ever show that internal "broken image" image anymore? I'll go work on bullet proofing necko to handle this case and attach a patch.
we change the frame into a tiny textnode. hixie says this is the correct behavior.
simply bullet proofing necko will lead to asserts and then a crash in layout. here's the crash: nsImageFrame::Paint(nsImageFrame * const 0x01219ce8, nsIPresContext * 0x067fe430, nsIRenderingContext & {...}, const nsRect & {x=0 y=0 width=9000 height=9000}, nsFramePaintLayer eFramePaintLayer_Underlay) line 985 + 53 bytes nsContainerFrame::PaintChild(nsIPresContext * 0x067fe430, nsIRenderingContext & {...}, const nsRect & {x=-120 y=-120 width=19140 height=12705}, nsIFrame * 0x01219ce8, nsFramePaintLayer eFramePaintLayer_Underlay) line 208 nsBlockFrame::PaintChildren(nsIPresContext * 0x067fe430, nsIRenderingContext & {...}, const nsRect & {x=-120 y=-120 width=19140 height=12705}, nsFramePaintLayer eFramePaintLayer_Underlay) line 6594 nsBlockFrame::Paint(nsBlockFrame * const 0x01219c10, nsIPresContext * 0x067fe430, nsIRenderingContext & {...}, const nsRect & {x=-120 y=-120 width=19140 height=12705}, nsFramePaintLayer eFramePaintLayer_Underlay) line 6472 nsContainerFrame::PaintChild(nsIPresContext * 0x067fe430, nsIRenderingContext & {...}, const nsRect & {x=0 y=0 width=19140 height=12705}, nsIFrame * 0x01219c10, nsFramePaintLayer eFramePaintLayer_Underlay) line 208 nsBlockFrame::PaintChildren(nsIPresContext * 0x067fe430, nsIRenderingContext & {...}, const nsRect & {x=0 y=0 width=19140 height=12705}, nsFramePaintLayer eFramePaintLayer_Underlay) line 6594 nsBlockFrame::Paint(nsBlockFrame * const 0x01219b88, nsIPresContext * 0x067fe430, nsIRenderingContext & {...}, const nsRect & {x=0 y=0 width=19140 height=12705}, nsFramePaintLayer eFramePaintLayer_Underlay) line 6472 nsContainerFrame::PaintChild(nsIPresContext * 0x067fe430, nsIRenderingContext & {...}, const nsRect & {x=0 y=0 width=19140 height=12705}, nsIFrame * 0x01219b88, nsFramePaintLayer eFramePaintLayer_Underlay) line 208 nsContainerFrame::PaintChildren(nsIPresContext * 0x067fe430, nsIRenderingContext & {...}, const nsRect & {x=0 y=0 width=19140 height=12705}, nsFramePaintLayer eFramePaintLayer_Underlay) line 152 nsHTMLContainerFrame::Paint(nsHTMLContainerFrame * const 0x01218e24, nsIPresContext * 0x067fe430, nsIRenderingContext & {...}, const nsRect & {x=0 y=0 width=19140 height=12705}, nsFramePaintLayer eFramePaintLayer_Underlay) line 108 PresShell::Paint(PresShell * const 0x0676d1a4, nsIView * 0x05275270, nsIRenderingContext & {...}, const nsRect & {x=0 y=0 width=19140 height=12705}) line 4945 + 34 bytes nsView::Paint(nsView * const 0x05275270, nsIRenderingContext & {...}, const nsRect & {x=0 y=0 width=19140 height=12705}, unsigned int 128, int & 268592757) line 275 nsViewManager::RenderDisplayListElement(DisplayListElement2 * 0x05e8f6c0, nsIRenderingContext & {...}) line 1394 nsViewManager::RenderViews(nsIView * 0x04d81ed0, nsIRenderingContext & {...}, const nsRect & {x=0 y=0 width=19140 height=12705}, int & 0) line 1319 nsViewManager::Refresh(nsIView * 0x04d81ed0, nsIRenderingContext * 0x05e8f950, const nsRect * 0x0012f694 {x=0 y=0 width=19140 height=12705}, unsigned int 1) line 885 nsViewManager::DispatchEvent(nsViewManager * const 0x0676e030, nsGUIEvent * 0x0012f7d4, nsEventStatus * 0x0012f6d8) line 1913 HandleEvent(nsGUIEvent * 0x0012f7d4) line 68 nsWindow::DispatchEvent(nsWindow * const 0x04d83164, nsGUIEvent * 0x0012f7d4, nsEventStatus & nsEventStatus_eIgnore) line 701 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f7d4, nsEventStatus & nsEventStatus_eIgnore) line 727 nsWindow::OnPaint() line 3831 + 28 bytes nsWindow::ProcessMessage(unsigned int 15, unsigned int 0, long 0, long * 0x0012fbb4) line 2838 + 17 bytes nsWindow::WindowProc(HWND__ * 0x000508da, unsigned int 15, unsigned int 0, long 0) line 956 + 27 bytes USER32! 77e719d0() USER32! 77e71982() NTDLL! 77f763a3() pavlov, do you want this bad boy?
*** Bug 74035 has been marked as a duplicate of this bug. ***
why is it crashing there? null pointer ?
yes, the mImageRequest is null.
maybe i'm blind, but everything in that function looks like it should check for mImageRequest being null.
with this patch, i don't see how it can crash from mImageRequest being null... although, i still don't see how it would crash in nsImageFrame::Paint without this patch.
Did this make it in? If not will the patch make it in for 0.9? cc'ing varada so he can mark some bugs as dups that I think have a similar stack trace.
I've rebuilt and I'm not seeing this crasher anymore. I do get an assert in IOService because the scheme is empty, but I can live with that: NTDLL! 77f7629c() nsDebug::Assertion(const char * 0x016c03d4, const char * 0x016c03cc, const char * 0x016c0394, int 219) line 286 + 13 bytes nsDebug::WarnIfFalse(const char * 0x016c03d4, const char * 0x016c03cc, const char * 0x016c0394, int 219) line 392 + 21 bytes nsIOService::GetProtocolHandler(nsIOService * const 0x01523f30, const char * 0x00000000, nsIProtocolHandler * * 0x0012edd4) line 219 + 32 bytes nsIOService::NewChannelFromURI(nsIOService * const 0x01523f30, nsIURI * 0x04c1e984, nsIChannel * * 0x0012eee4) line 309 + 46 bytes imgLoader::LoadImage(imgLoader * const 0x023988a0, nsIURI * 0x04c1e984, nsILoadGroup * 0x07145050, imgIDecoderObserver * 0x04c1fc80, nsISupports * 0x075099d0, imgIRequest * * 0x0586ae0c) line 117 + 69 bytes nsImageFrame::Init(nsImageFrame * const 0x0586ad78, nsIPresContext * 0x075099d0, nsIContent * 0x04c1eb90, nsIFrame * 0x0586aca0, nsIStyleContext * 0x04c1fdf0, nsIFrame * 0x00000000) line 303 + 111 bytes nsCSSFrameConstructor::InitAndRestoreFrame(nsIPresContext * 0x075099d0, nsFrameConstructorState & {...}, nsIContent * 0x04c1eb90, nsIFrame * 0x0586aca0, nsIStyleContext * 0x04c1fdf0, nsIFrame * 0x00000000, nsIFrame * 0x0586ad78) line 6663 + 32 bytes nsCSSFrameConstructor::ConstructFrameByTag(nsIPresShell * 0x07484540, nsIPresContext * 0x075099d0, nsFrameConstructorState & {...}, nsIContent * 0x04c1eb90, nsIFrame * 0x0586aca0, nsIAtom * 0x01552780 {"img"}, int 3, nsIStyleContext * 0x04c1fdf0, nsFrameItems & {...}) line 4926 nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x07484540, nsIPresContext * 0x075099d0, nsFrameConstructorState & {...}, nsIContent * 0x04c1eb90, nsIFrame * 0x0586aca0, nsIAtom * 0x01552780 {"img"}, int 3, nsIStyleContext * 0x04c1fdf0, nsFrameItems & {...}, int 0) line 7181 + 52 bytes nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x07484540, nsIPresContext * 0x075099d0, nsFrameConstructorState & {...}, nsIContent * 0x04c1eb90, nsIFrame * 0x0586aca0, nsFrameItems & {...}) line 7091 + 56 bytes nsCSSFrameConstructor::ContentAppended(nsCSSFrameConstructor * const 0x074848d0, nsIPresContext * 0x075099d0, nsIContent * 0x074945a0, int 0) line 8083 StyleSetImpl::ContentAppended(StyleSetImpl * const 0x07484a00, nsIPresContext * 0x075099d0, nsIContent * 0x074945a0, int 0) line 1241 PresShell::ContentAppended(PresShell * const 0x07484548, nsIDocument * 0x07503290, nsIContent * 0x074945a0, int 0) line 4724 + 46 bytes nsDocument::ContentAppended(nsDocument * const 0x07503290, nsIContent * 0x074945a0, int 0) line 1537 nsHTMLDocument::ContentAppended(nsHTMLDocument * const 0x07503290, nsIContent * 0x074945a0, int 0) line 1294 + 17 bytes HTMLContentSink::NotifyAppend(nsIContent * 0x074945a0, int 0) line 4574 SinkContext::FlushTags(int 1) line 2046 HTMLContentSink::CloseBody(HTMLContentSink * const 0x07505610, const nsIParserNode & {...}) line 2902 CNavDTD::CloseBody(const nsIParserNode * 0x0580d4b8) line 3134 + 31 bytes CNavDTD::CloseContainer(const nsCParserNode * 0x0580d4b8, nsHTMLTag eHTMLTag_body, int 0) line 3532 + 12 bytes CNavDTD::CloseContainersTo(int 1, nsHTMLTag eHTMLTag_body, int 0) line 3593 + 20 bytes CNavDTD::CloseContainersTo(nsHTMLTag eHTMLTag_body, int 0) line 3750 + 20 bytes CNavDTD::DidBuildModel(CNavDTD * const 0x0748e900, unsigned int 0, int 1, nsIParser * 0x07505ec0, nsIContentSink * 0x07505610) line 579 nsParser::DidBuildModel(unsigned int 0) line 1418 + 60 bytes nsParser::ResumeParse(int 1, int 1) line 1901 nsParser::OnStopRequest(nsParser * const 0x07505ec8, nsIRequest * 0x074fae74, nsISupports * 0x065e2e50, unsigned int 0) line 2342 + 19 bytes nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x074fa4c0, nsIRequest * 0x074fae74, nsISupports * 0x065e2e50, unsigned int 0) line 277 nsStreamConverter::OnStopRequest(nsStreamConverter * const 0x074fa410, nsIRequest * 0x074fae74, nsISupports * 0x065e2e50, unsigned int 0) line 1013 nsMsgProtocol::OnStopRequest(nsMsgProtocol * const 0x074fae70, nsIRequest * 0x074fa624, nsISupports * 0x065e2e50, unsigned int 0) line 271 + 88 bytes nsMailboxProtocol::OnStopRequest(nsMailboxProtocol * const 0x074fae70, nsIRequest * 0x074fa624, nsISupports * 0x065e2e50, unsigned int 0) line 204 nsOnStopRequestEvent::HandleEvent() line 159 nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x074fb314) line 64 PL_HandleEvent(PLEvent * 0x074fb314) line 588 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00a0ad80) line 518 + 9 bytes _md_EventReceiverProc(HWND__ * 0x000d00da, unsigned int 49337, unsigned int 0, long 10530176) line 1069 + 9 bytes USER32! 77e71820() 00a0ad80() I'm checking if I've got patches from pavlov in my tree that need to be checked in. if yes, I'll attach them here. if no, I'll mark this fixed.
I have one fix in my tree that needs to be checked in. it's a bullet proofing fix to nsStdURL.cpp to allow for the case where scheme is null. here it comes, can I get a review?
adding darin and valeski to the cc list, for review of the netwerk change.
r/sr=darin on the mScheme check... but please make sure the indentation is consistent ;-)
will do on the indentation. once I get this landed, I'll log a bug on the remaining assertion.
this has r=mscott. waiting for drivers@mozilla.org
actually, mScheme is not allowed to be null. see http://bugzilla.mozilla.org/show_bug.cgi?id=73845. for now, the null checks above necko are the solution (until 73845 is fixed). please do not add this check to nsStdURL as it will hide the real problem.
ok, I'll work on the caller.
here comes the patch. we should remove this extra string copy when #73845 gets fixed.
Depends on: 73845
r=mscott
r=valeski on the ::SchemeIs() call in mail/news (4/18/01 16:19 patch).
a=blizzard for 0.9
fixed. thanks blizzard.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
*** Bug 74840 has been marked as a duplicate of this bug. ***
*** Bug 76706 has been marked as a duplicate of this bug. ***
*** Bug 76667 has been marked as a duplicate of this bug. ***
note, messages with img tags without src attributes and with relative src attributes caused this problem. examples: <img alt="foo"> <img src="foo.gif" alt="foo">
*** Bug 76387 has been marked as a duplicate of this bug. ***
Using build 2001-05-03 on win, mac and linux, I opened the attachment and did a send page to myself. I opened the mail msg without crashing. I did not see the problem back with build 4-16 so I'm not sure if this is all I need to do to test this. I will check some of the duplicates too to see if those are also fixed. If the reporter could check this to that would be great.
Yes, this bug is a history for me, too. Marking VERIFIED.
Status: RESOLVED → VERIFIED
Thanks!
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: