This HTML crashes the M4 viewer: <img style="float:left;"> Only an image without a src attribute crashes when it is floated. The following examples do *not* crash the viewer: <img style="float:left;" src="x"> I assigned this to imagelib because this crash only happens with images. Either layout or the parser may be involved.

Moving to parser.

Eric: Are you handling style bugz? If this isn't yours, could you reassign... thx, pn.

Nope, I'm doing forms and framesets. Is there a stack trace for this bug? That would help narrow down who we should assign it too. This isn't a forms or framesets issue, so I'm guessing it's not mine, handing it off to the CSS guru for appropriate redistribution...

What I see is that we crash when quitting the app (see the stack trace below), because the frame pointer passed into StopAllLoadImagesFor() is NULL. Kipp, your recent image changes must have changed something. Previously there was code (I know because I added it) that would check for no SRC attribute value and would call CantRenderReplacedElement() in that case That code doesn't seem to be there (or isn't triggered) anymore, because we never call CantRenderReplacedElement(). nsPresContext::StopAllLoadImagesFor(nsPresContext * const 0x02471ae0, nsIFrame * 0x00000000) line 781 + 7 bytes nsHTMLImageLoader::StopAllLoadImages(nsIPresContext * 0x02471ae0) line 119 nsImageFrame::DeleteFrame(nsImageFrame * const 0x0114de50, nsIPresContext & {...}) line 90 nsFrameList::DeleteFrames(nsIPresContext & {...}) line 29 nsBlockFrame::DeleteFrame(nsBlockFrame * const 0x0114e6e0, nsIPresContext & {...}) line 805 nsLineBox::DeleteLineList(nsIPresContext & {...}, nsLineBox * 0x0114e620) line 234 nsBlockFrame::DeleteFrame(nsBlockFrame * const 0x0114eb70, nsIPresContext & {...}) line 800 + 16 bytes nsAreaFrame::DeleteFrame(nsAreaFrame * const 0x0114eb70, nsIPresContext & {...}) line 102 nsFrameList::DeleteFrames(nsIPresContext & {...}) line 29 nsContainerFrame::DeleteFrame(nsContainerFrame * const 0x0114ef60, nsIPresContext & {...}) line 82 nsFrameList::DeleteFrames(nsIPresContext & {...}) line 29 nsContainerFrame::DeleteFrame(nsContainerFrame * const 0x0114f9b0, nsIPresContext & {...}) line 82 nsFrameList::DeleteFrames(nsIPresContext & {...}) line 29 nsContainerFrame::DeleteFrame(nsContainerFrame * const 0x0114fda0, nsIPresContext & {...}) line 82 ViewportFrame::DeleteFrame(ViewportFrame * const 0x0114fda0, nsIPresContext & {...}) line 112 PresShell::~PresShell() line 549 PresShell::`scalar deleting destructor'(unsigned int 1) + 15 bytes PresShell::Release(PresShell * const 0x01145490) line 489 + 34 bytes DocumentViewerImpl::~DocumentViewerImpl() line 216 + 18 bytes DocumentViewerImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes DocumentViewerImpl::Release(DocumentViewerImpl * const 0x02471040) line 153 + 99 bytes nsWebShell::Destroy(nsWebShell * const 0x010c7900) line 885 + 27 bytes nsBrowserWindow::Close(nsBrowserWindow * const 0x010c6180) line 1561 nsBrowserWindow::CloseAllWindows() line 298 nsViewerApp::Destroy() line 171 nsViewerApp::Exit(nsViewerApp * const 0x010729e0) line 328 nsBrowserWindow::DispatchMenuItem(int 40002) line 503 nsNativeBrowserWindow::DispatchMenuItem(int 40002) line 93 HandleBrowserEvent(nsGUIEvent * 0x0012fea4) line 335 + 18 bytes nsWindow::DispatchEvent(nsWindow * const 0x0114c6d4, nsGUIEvent * 0x0012fea4, nsEventStatus & nsEventStatus_eIgnore) line 414 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fea4) line 435 nsWindow::ProcessMessage(unsigned int 273, unsigned int 40002, long 0, long * 0x0012fef4) line 1990 + 21 bytes nsWindow::WindowProc(HWND__ * 0x009504d6, unsigned int 273, unsigned int 40002, long 0) line 478 + 27 bytes USER32! 77e71250()

Fixed. Images w/o src attributes no longer crash.

I can't reproduce this problem with the current build, or with the builds released around the date in which this bug was authored. bloviate@yahoo.com, could you please give your thumbs-up or thumbs-down on whether this is fixed to your satisfaction? Thanks!

Giving my thumbs-up; I haven't been able to reproduce this bug.

Thank you! (verified)

*** Bug 3520 has been marked as a duplicate of this bug. ***