Talkback ids: TB38005358X TB38005632Q TB38011091W Build: 2001111303 Win32 When visiting cnn.com with image confirmation on, you are presented with a long sequence of images to accept or deny. I was accepting each one, telling mozilla to not remember my choice. I was planning to check each in Page Info -> Images befor I blocked servers. When I neared completing the sequence, mozilla crashed.

Confirmed here using W2K build 2001111403 and under RH Linux 7.2 with the same nightly build. Someone should set platform and OS to All.

Same over here with Linux 2001111408 ---> NEW

CC stephen for talkback TB38005358X,TB38005632Q,TB38011091W

Stack Signature SinkContext::FlushTags 268540f9 Bug ID Trigger Time 2001-11-14 09:12:10 Email Address mythdraug@pobox.com URL visited mozillanews.org User Comments near completing a long string of image accept/deny accept then crash Build ID 2001111309 Product ID MozillaTrunk Platform Operating System Win32 Module Trigger Reason Access violation Stack Trace SinkContext::FlushTags [d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLContentSink.cpp, line 2218] HTMLContentSink::BeginUpdate [d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLContentSink.cpp, line 4864] nsDocument::BeginUpdate [d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 1568] nsEventStateManager::SetContentState [d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 3421] nsGenericHTMLElement::HandleDOMEventForAnchors [d:\builds\seamonkey\mozilla\content\html\content\src\nsGenericHTMLElement.cpp, line 1459] nsHTMLLinkElement::HandleDOMEvent [d:\builds\seamonkey\mozilla\content\html\content\src\nsHTMLLinkElement.cpp, line 342] nsGenericElement::HandleDOMEvent [d:\builds\seamonkey\mozilla\content\base\src\nsGenericElement.cpp, line 1901] nsHTMLImageElement::HandleDOMEvent [d:\builds\seamonkey\mozilla\content\html\content\src\nsHTMLImageElement.cpp, line 582] nsEventStateManager::GenerateMouseEnterExit [d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 2156] nsEventStateManager::PreHandleEvent [d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 364] PresShell::HandleEventInternal [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5812] PresShell::HandleEvent [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5742] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 375] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 348] nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 348] nsViewManager::DispatchEvent [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1874] HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 84] nsWindow::DispatchEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 748] nsWindow::DispatchWindowEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 765] nsWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4317] ChildWindow::DispatchMouseEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4567] nsWindow::ProcessMessage [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3283] nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1013] USER32.DLL + 0x2e98 (0x77e12e98) USER32.DLL + 0x30e0 (0x77e130e0) USER32.DLL + 0x5824 (0x77e15824) nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 303] main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1316] main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1633] WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1651] WinMainCRTStartup() KERNEL32.DLL + 0x17d08 (0x77e97d08)

-> Parser (?)

Related to bug 110269?

sounds like a DOM bug to me. Johnny?

Hmm, hard to say what could've caused this from looking at the stack trace, is this still reproduceable?

wfm, Linux 2001120512 no crash, no problem Do you guys still experience the crash?

WFM with 2001-12-10-03: marking WFM

verified WFM with build ID 20020110 on win2k

I've been seeing this for several weeks, and I finally added enough swap to capture a backtrace. Details: I get this crash immediately after clicking on an image confirmation dialog. The dialog disappears and it crashes. The host I'm browsing is irrelevant. Clobber build, fresh profile, CVS pull: checkout start: Thu Mar 14 19:53:52 PST 2002 checkout finish: Thu Mar 14 20:01:37 PST 2002 drbrain@PII350$ uname -a FreeBSD PII350.home.segment7.net 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Fri Feb 22 00:51:23 PST 2002 root@PII350.home.segment7.net:/disks/current/obj/disks/current/src/sys/PII350 i386 #0 0x2842ea3b in XFillRectangle () from /usr/X11R6/lib/libX11.so.6 #1 0x283c0c8a in gdk_draw_rectangle () from /usr/X11R6/lib/libgdk12.so.2 #2 0x28ec6cb1 in nsRenderingContextGTK::FillRect (this=0x8821600, aX=0, aY=0, aWidth=14212, aHeight=9424) at nsRenderingContextGTK.cpp:972 #3 0x28ec6bbf in nsRenderingContextGTK::FillRect (this=0x8821600, aRect=@0xbfbff070) at nsRenderingContextGTK.cpp:945 #4 0x29290576 in nsCSSRendering::PaintBackgroundWithSC ( aPresContext=0x89ed800, aRenderingContext=@0x8821600, aForFrame=0x8a81160, aDirtyRect=@0xbfbff264, aBorderArea=@0xbfbff070, aColor=@0xbfbfefec, aBorder=@0x8d16010, aDX=0, aDY=0, aUsePrintSettings=0) at nsCSSRendering.cpp:2760 #5 0x2929008f in nsCSSRendering::PaintBackground (aPresContext=0x89ed800, aRenderingContext=@0x8821600, aForFrame=0x8a81160, irtyRect=@0xbfbff264, aBorderArea=@0xbfbff070, aBorder=@0x8d16010, aDX=0, aDY=0, aUsePrintSettings=0) at nsCSSRendering.cpp:2633 #6 0x291efbef in nsHTMLContainerFrame::Paint (this=0x8a81160, aPresContext=0x89ed800, aRenderingContext=@0x8821600, aDirtyRect=@0xbfbff264, aWhichLayer=eFramePaintLayer_Underlay, aFlags=0) at nsHTMLContainerFrame.cpp:95 #7 0x291f0fc5 in CanvasFrame::Paint (this=0x8a81160, aPresContext=0x89ed800, aRenderingContext=@0x8821600, aDirtyRect=@0xbfbff264, aWhichLayer=eFramePaintLayer_Underlay, aFlags=0) at nsHTMLFrame.cpp:388 #8 0x292232f3 in PresShell::Paint (this=0x88f9800, aView=0x8cf4f80, aRenderingContext=@0x8821600, aDirtyRect=@0xbfbff264) at nsPresShell.cpp:5749 #9 0x294203e7 in nsView::Paint (this=0x8cf4f80, rc=@0x8821600, rect=@0xbfbff264, aPaintFlags=0, aResult=@0xbfbff244) at nsView.cpp:278 #10 0x29429d7d in nsViewManager::RenderDisplayListElement (this=0x89e9d00, element=0x8aa54c0, aRC=@0x8821600) at nsViewManager.cpp:1173 #11 0x29429bca in nsViewManager::RenderViews (this=0x89e9d00, aRootView=0x8c8d500, aRC=@0x8821600, aRect=@0xbfbff39c, aResult=@0xbfbff37c) at nsViewManager.cpp:1121 #12 0x29428a2d in nsViewManager::Refresh (this=0x89e9d00, aView=0x8c8d500, aContext=0x8821600, aRegion=0x8abf140, aUpdateFlags=1) at nsViewManager.cpp:718 #13 0x2942b1ef in nsViewManager::DispatchEvent (this=0x89e9d00, aEvent=0xbfbff558, aStatus=0xbfbff4b0) at nsViewManager.cpp:1708 #14 0x2941fe95 in HandleEvent (aEvent=0xbfbff558) at nsView.cpp:80 #15 0x28dd14ae in nsWidget::DispatchEvent (this=0x8b13400, aEvent=0xbfbff558, aStatus=@0xbfbff510) at nsWidget.cpp:1406 #16 0x28dd13b5 in nsWidget::DispatchWindowEvent (this=0x8b13400, event=0xbfbff558) at nsWidget.cpp:1294 #17 0x28dd4a0b in nsWindow::DoPaint (this=0x8b13400, aX=0, aY=0, aWidth=748, aHeight=496, aClipRegion=0x8ac98f0) at nsWindow.cpp:759 #18 0x28dd4be7 in nsWindow::Update (this=0x8b13400) at nsWindow.cpp:805 #19 0x28dd4895 in nsWindow::UpdateIdle (data=0x0) at nsWindow.cpp:668 #20 0x283f2cae in g_idle_dispatch () from /usr/local/lib/libglib12.so.3 #21 0x283f1c8b in g_main_dispatch () from /usr/local/lib/libglib12.so.3 #22 0x283f22b4 in g_main_iterate () from /usr/local/lib/libglib12.so.3 #23 0x283f244c in g_main_run () from /usr/local/lib/libglib12.so.3 #24 0x283127f7 in gtk_main () from /usr/X11R6/lib/libgtk12.so.2 #25 0x28dc4070 in nsAppShell::Run (this=0x814a870) at nsAppShell.cpp:364 #26 0x28d945da in nsAppShellService::Run (this=0x811e580) at nsAppShellService.cpp:308 #27 0x8050e2f in main1 (argc=1, argv=0xbfbff958, nativeApp=0x80880c0) at nsAppRunner.cpp:1350 #28 0x80517f0 in main (argc=1, argv=0xbfbff958) at nsAppRunner.cpp:1698

The stack points to rendering. --> Kevin.

Ok, here's another stack trace, this one gives a Bus error rather than a SegV (They're different somehow on FreeBSD, I can't remember how.) BTW, I'm running Xinerama on this machine, if it makes any difference. In this stack, the confirmation prompt does not disappear, in fact, there was a slightly larger one behind it that showed a border, but it crashed before the one I clicked on fully disappeared. The WM would focus that lower window, but not the one I hit the Yes button it. (BTW, Component RDF?) #0 0x283c0c54 in gdk_draw_rectangle () from /usr/X11R6/lib/libgdk12.so.2 #1 0x28ec6cb1 in nsRenderingContextGTK::FillRect (this=0x8973000, aX=0, aY=0, aWidth=14212, aHeight=8322) at nsRenderingContextGTK.cpp:972 #2 0x28ec6bbf in nsRenderingContextGTK::FillRect (this=0x8973000, aRect=@0xbfbfc454) at nsRenderingContextGTK.cpp:945 #3 0x29290576 in nsCSSRendering::PaintBackgroundWithSC ( aPresContext=0x883a400, aRenderingContext=@0x8973000, aForFrame=0x88cd160, aDirtyRect=@0xbfbfc648, aBorderArea=@0xbfbfc454, aColor=@0xbfbfc3d0, aBorder=@0x88df010, aDX=0, aDY=0, aUsePrintSettings=0) at nsCSSRendering.cpp:2760 #4 0x2929008f in nsCSSRendering::PaintBackground (aPresContext=0x883a400, aRenderingContext=@0x8973000, aForFrame=0x88cd160, aDirtyRect=@0xbfbfc648, aBorderArea=@0xbfbfc454, aBorder=@0x88df010, aDX=0, aDY=0, aUsePrintSettings=0) at nsCSSRendering.cpp:2633 #5 0x291efbef in nsHTMLContainerFrame::Paint (this=0x88cd160, aPresContext=0x883a400, aRenderingContext=@0x8973000, aDirtyRect=@0xbfbfc648, aWhichLayer=eFramePaintLayer_Underlay, aFlags=0) at nsHTMLContainerFrame.cpp:95 #6 0x291f0fc5 in CanvasFrame::Paint (this=0x88cd160, aPresContext=0x883a400, aRenderingContext=@0x8973000, aDirtyRect=@0xbfbfc648, aWhichLayer=eFramePaintLayer_Underlay, aFlags=0) at nsHTMLFrame.cpp:388 #7 0x292232f3 in PresShell::Paint (this=0x87edc00, aView=0x8882780, aRenderingContext=@0x8973000, aDirtyRect=@0xbfbfc648) at nsPresShell.cpp:5749 #8 0x294203e7 in nsView::Paint (this=0x8882780, rc=@0x8973000, rect=@0xbfbfc648, aPaintFlags=0, aResult=@0xbfbfc628) at nsView.cpp:278 #9 0x29429d7d in nsViewManager::RenderDisplayListElement (this=0x81f1a00, element=0x89484c0, aRC=@0x8973000) at nsViewManager.cpp:1173 #10 0x29429bca in nsViewManager::RenderViews (this=0x81f1a00, aRootView=0x8902400, aRC=@0x8973000, aRect=@0xbfbfc780, aResult=@0xbfbfc760) at nsViewManager.cpp:1121 #11 0x29428a2d in nsViewManager::Refresh (this=0x81f1a00, aView=0x8902400, aContext=0x8973000, aRegion=0x8958450, aUpdateFlags=1) at nsViewManager.cpp:718 #12 0x2942b1ef in nsViewManager::DispatchEvent (this=0x81f1a00, aEvent=0xbfbfc93c, aStatus=0xbfbfc894) at nsViewManager.cpp:1708 #13 0x2941fe95 in HandleEvent (aEvent=0xbfbfc93c) at nsView.cpp:80 #14 0x28dd14ae in nsWidget::DispatchEvent (this=0x8676000, aEvent=0xbfbfc93c, aStatus=@0xbfbfc8f4) at nsWidget.cpp:1406 #15 0x28dd13b5 in nsWidget::DispatchWindowEvent (this=0x8676000, event=0xbfbfc93c) at nsWidget.cpp:1294 #16 0x28dd4a0b in nsWindow::DoPaint (this=0x8676000, aX=0, aY=0, aWidth=748, aHeight=438, aClipRegion=0x8920310) at nsWindow.cpp:759 #17 0x28dd4be7 in nsWindow::Update (this=0x8676000) at nsWindow.cpp:805 #18 0x28dd4895 in nsWindow::UpdateIdle (data=0x0) at nsWindow.cpp:668 #19 0x283f2cae in g_idle_dispatch () from /usr/local/lib/libglib12.so.3 #20 0x283f1c8b in g_main_dispatch () from /usr/local/lib/libglib12.so.3 #21 0x283f22b4 in g_main_iterate () from /usr/local/lib/libglib12.so.3 #22 0x283f2369 in g_main_iteration () from /usr/local/lib/libglib12.so.3 #23 0x28dc40f6 in nsAppShell::DispatchNativeEvent (this=0x8958250, aRealEvent=0, aEvent=0x0) at nsAppShell.cpp:401 #24 0x28d8d3a1 in nsXULWindow::ShowModal (this=0x896b500) at nsXULWindow.cpp:285 #25 0x28d98d0a in nsWebShellWindow::ShowModal (this=0x896b500) at nsWebShellWindow.cpp:1088 #26 0x28d8b0b6 in nsContentTreeOwner::ShowAsModal (this=0x88fff00) at nsContentTreeOwner.cpp:441 #27 0x2861a37c in nsWindowWatcher::OpenWindowJS (this=0x815b7c0, aParent=0x81f1704, aUrl=0x28633280 "chrome://global/content/commonDialog.xul", aName=0x28633423 "_blank", aFeatures=0x28633400 "centerscreen,chrome,modal,titlebar", aDialog=1, argc=1, argv=0x8712870, _retval=0xbfbfce94) at nsWindowWatcher.cpp:704 #28 0x28619145 in nsWindowWatcher::OpenWindow (this=0x815b7c0, aParent=0x81f1704, aUrl=0x28633280 "chrome://global/content/commonDialog.xul", aName=0x28633423 "_blank", aFeatures=0x28633400 "centerscreen,chrome,modal,titlebar", aArguments=0x893fa00, _retval=0xbfbfce94) at nsWindowWatcher.cpp:451 #29 0x286180d8 in nsPromptService::DoDialog (this=0x87da280, aParent=0x81f1704, aParamBlock=0x893fa00, aChromeURL=0x28633280 "chrome://global/content/commonDialog.xul") at nsPromptService.cpp:629 #30 0x28617074 in nsPromptService::ConfirmEx (this=0x87da280, parent=0x0, dialogTitle=0x87127b0, text=0x896b000, buttonFlags=0, button0Title=0x0, button1Title=0x0, button2Title=0x0, checkMsg=0x893f940, checkValue=0xbfbfd150, buttonPressed=0xbfbfd060) at nsPromptService.cpp:347 #31 0x286159ac in nsPrompt::ConfirmEx (this=0x8895880, dialogTitle=0x87127b0, text=0x896b000, buttonFlags=1027, button0Title=0x0, button1Title=0x0, button2Title=0x0, checkMsg=0x893f940, checkValue=0xbfbfd150, buttonPressed=0xbfbfd060) at nsPrompt.cpp:166 #32 0x28d710f1 in permission_CheckConfirmYN (aPrompter=0x0, szMessage=0x896b000, szCheckMessage=0x893f940, checkValue=0xbfbfd150) at nsPermissions.cpp:100 #33 0x28d713d2 in Permission_Check (aPrompter=0x0, hostname=0xbfbfd340 "www.thinkgeek.com", type=1, warningPref=1, message=0x896b000) at nsPermissions.cpp:204 #34 0x28d70da2 in IMAGE_CheckForPermission ( hostname=0xbfbfd340 "www.thinkgeek.com", firstHostname=0xbfbfd390 "www.thinkgeek.com", permission=0xbfbfd4c8) at nsImages.cpp:191 #35 0x28d6ae79 in nsImgManager::ShouldLoad (this=0x86ef380, aContentType=2, aContentLoc=0x892eb00, aContext=0x8910f20, aWindow=0x8622404, _retval=0xbfbfd4c8) at nsImgManager.cpp:137 #36 0x28bdd6f0 in nsContentPolicy::CheckPolicy (this=0x85d8cc0, policyType=0, contentType=2, contentLocation=0x892eb00, context=0x8910f20, window=0x8622404, shouldProceed=0xbfbfd4c8) at nsContentPolicy.cpp:143 #37 0x28bdd768 in nsContentPolicy::ShouldLoad (this=0x85d8cc0, contentType=2, contentLocation=0x892eb00, context=0x8910f20, window=0x8622404, shouldLoad=0xbfbfd4c8) at nsContentPolicy.cpp:166 #38 0x291fc752 in nsImageFrame::CanLoadImage (this=0x8b01e94, aURI=0x892eb00) at ../../../../dist/include/content/nsContentPolicyUtils.h:56 #39 0x291fa8f9 in nsImageFrame::RealLoadImage (this=0x8b01e94, aSpec=@0xbfbfd5f8, aPresContext=0x883a400, aRequest=0x8921500) at nsImageFrame.cpp:1891 #40 0x291fa824 in nsImageFrame::LoadImage (this=0x8b01e94, aSpec=@0xbfbfd5f8, aPresContext=0x883a400, aRequest=0x8921500) at nsImageFrame.cpp:1865 #41 0x291f6372 in nsImageFrame::Init (this=0x8b01e94, aPresContext=0x883a400, aContent=0x8910f00, aParent=0x8b01c98, aContext=0x8b01db0, aPrevInFlow=0x0) at nsImageFrame.cpp:319 #42 0x2927906d in nsCSSFrameConstructor::InitAndRestoreFrame (this=0x883b200, aPresContext=0x883a400, aState=@0xbfbfe4e0, aContent=0x8910f00, aParentFrame=0x8b01c98, aStyleContext=0x8b01db0, aPrevInFlow=0x0, aNewFrame=0x8b01e94) at nsCSSFrameConstructor.cpp:6562 #43 0x292752ff in nsCSSFrameConstructor::ConstructHTMLFrame (this=0x883b200, aPresShell=0x87edc00, aPresContext=0x883a400, aState=@0xbfbfe4e0, aContent=0x8910f00, aParentFrame=0x8b01c98, aTag=0x80cb380, aNameSpaceID=3, aStyleContext=0x8b01db0, aFrameItems=@0xbfbfda10) at nsCSSFrameConstructor.cpp:4763 #44 0x2927a22d in nsCSSFrameConstructor::ConstructFrameInternal ( this=0x883b200, aPresShell=0x87edc00, aPresContext=0x883a400, aState=@0xbfbfe4e0, aContent=0x8910f00, aParentFrame=0x8b01c98, aTag=0x80cb380, aNameSpaceID=3, aStyleContext=0x8b01db0, aFrameItems=@0xbfbfda10, aXBLBaseTag=0) at nsCSSFrameConstructor.cpp:7123 #45 0x29279e7b in nsCSSFrameConstructor::ConstructFrame (this=0x883b200, aPresShell=0x87edc00, aPresContext=0x883a400, aState=@0xbfbfe4e0, aContent=0x8910f00, aParentFrame=0x8b01c98, aFrameItems=@0xbfbfda10) at nsCSSFrameConstructor.cpp:7022 #46 0x29287021 in nsCSSFrameConstructor::ProcessChildren (this=0x883b200, aPresShell=0x87edc00, aPresContext=0x883a400, aState=@0xbfbfe4e0, aContent=0x8910e80, aFrame=0x8b01c98, aCanHaveGeneratedContent=1, aFrameItems=@0xbfbfda10, aParentIsBlock=1, aTableCreator=0x0) at nsCSSFrameConstructor.cpp:12135 #47 0x292707ae in nsCSSFrameConstructor::ConstructTableCellFrame ( this=0x883b200, aPresShell=0x87edc00, aPresContext=0x883a400, aState=@0xbfbfe4e0, aContent=0x8910e80, aParentFrameIn=0x8b01b58, aStyleContext=0x8b01bd0, aTableCreator=@0xbfbfe260, aIsPseudo=0, aChildItems=@0xbfbfdc5c, aNewCellOuterFrame=@0xbfbfdab4, aNewCellInnerFrame=@0xbfbfdab0, aIsPseudoParent=@0xbfbfdabc) at nsCSSFrameConstructor.cpp:2726 #48 0x29271211 in nsCSSFrameConstructor::TableProcessChild (this=0x883b200, aPresShell=0x87edc00, aPresContext=0x883a400, aState=@0xbfbfe4e0, aChildContent=0x8910e80, aParentContent=0x8910dc0, aParentFrame=0x8b01b58, aParentFrameType=0x80ec580, aParentStyleContext=0x8b01aec, aTableCreator=@0xbfbfe260, aChildItems=@0xbfbfdc5c, aCaption=@0xbfbfdc58) at nsCSSFrameConstructor.cpp:2973 #49 0x29270e79 in nsCSSFrameConstructor::TableProcessChildren (this=0x883b200, aPresShell=0x87edc00, aPresContext=0x883a400, aState=@0xbfbfe4e0, aContent=0x8910dc0, aParentFrame=0x8b01b58, aTableCreator=@0xbfbfe260, aChildItems=@0xbfbfdc5c, aCaption=@0xbfbfdc58) at nsCSSFrameConstructor.cpp:2883 #50 0x292700d2 in nsCSSFrameConstructor::ConstructTableRowFrame ( this=0x883b200, aPresShell=0x87edc00, aPresContext=0x883a400, aState=@0xbfbfe4e0, aContent=0x8910dc0, aParentFrameIn=0x8b01a88, aStyleContext=0x8b01aec, aTableCreator=@0xbfbfe260, aIsPseudo=0, aChildItems=@0xbfbfde68, aNewFrame=@0xbfbfdcc4, aIsPseudoParent=@0xbfbfdccc) at nsCSSFrameConstructor.cpp:2570 #51 0x2927119a in nsCSSFrameConstructor::TableProcessChild (this=0x883b200, aPresShell=0x87edc00, aPresContext=0x883a400, aState=@0xbfbfe4e0, aChildContent=0x8910dc0, aParentContent=0x8910d80, aParentFrame=0x8b01a88, aParentFrameType=0x80ec540, aParentStyleContext=0x8b01a58, aTableCreator=@0xbfbfe260, aChildItems=@0xbfbfde68, aCaption=@0xbfbfde64) at nsCSSFrameConstructor.cpp:2959 #52 0x29270e79 in nsCSSFrameConstructor::TableProcessChildren (this=0x883b200, aPresShell=0x87edc00, aPresContext=0x883a400, aState=@0xbfbfe4e0, aContent=0x8910d80, aParentFrame=0x8b01a88, aTableCreator=@0xbfbfe260, aChildItems=@0xbfbfde68, aCaption=@0xbfbfde64) at nsCSSFrameConstructor.cpp:2883 #53 0x2926fd16 in nsCSSFrameConstructor::ConstructTableRowGroupFrame ( this=0x883b200, aPresShell=0x87edc00, aPresContext=0x883a400, aState=@0xbfbfe4e0, aContent=0x8910d80, aParentFrameIn=0x8b01824, aStyleContext=0x8b01a58, aTableCreator=@0xbfbfe260, aIsPseudo=0, aChildItems=@0xbfbfe088, aNewFrame=@0xbfbfded4, aIsPseudoParent=@0xbfbfdedc) at nsCSSFrameConstructor.cpp:2461 #54 0x29271166 in nsCSSFrameConstructor::TableProcessChild (this=0x883b200, aPresShell=0x87edc00, aPresContext=0x883a400, aState=@0xbfbfe4e0, aChildContent=0x8910d80, aParentContent=0x88dbf40, aParentFrame=0x8b01824, aParentFrameType=0x80c6760, aParentStyleContext=0x8b01580, aTableCreator=@0xbfbfe260, aChildItems=@0xbfbfe088, aCaption=@0xbfbfe084) at nsCSSFrameConstructor.cpp:2953 #55 0x29270e79 in nsCSSFrameConstructor::TableProcessChildren (this=0x883b200, aPresShell=0x87edc00, aPresContext=0x883a400, aState=@0xbfbfe4e0, aContent=0x88dbf40, aParentFrame=0x8b01824, aTableCreator=@0xbfbfe260, aChildItems=@0xbfbfe088, aCaption=@0xbfbfe084) at nsCSSFrameConstructor.cpp:2883 #56 0x2926f8ca in nsCSSFrameConstructor::ConstructTableFrame (this=0x883b200, aPresShell=0x87edc00, aPresContext=0x883a400, aState=@0xbfbfe4e0, aContent=0x88dbf40, aParentFrameIn=0x88e9194, aStyleContext=0x8b01580, aTableCreator=@0xbfbfe260, aIsPseudo=0, aChildItems=@0xbfbfe4a8, aNewOuterFrame=@0xbfbfe180, aNewInnerFrame=@0xbfbfe130, aIsPseudoParent=@0xbfbfe134) at nsCSSFrameConstructor.cpp:2342 #57 0x29278ae3 in nsCSSFrameConstructor::ConstructFrameByDisplayType ( this=0x883b200, aPresShell=0x87edc00, aPresContext=0x883a400, aState=@0xbfbfe4e0, aDisplay=0x8b015b0, aContent=0x88dbf40, aParentFrame=0x88e9194, aStyleContext=0x8b01580, aFrameItems=@0xbfbfe4a8) at nsCSSFrameConstructor.cpp:6384 #58 0x2927a372 in nsCSSFrameConstructor::ConstructFrameInternal ( this=0x883b200, aPresShell=0x87edc00, aPresContext=0x883a400, aState=@0xbfbfe4e0, aContent=0x88dbf40, aParentFrame=0x88e9194, aTag=0x80cbc60, aNameSpaceID=3, aStyleContext=0x8b01580, aFrameItems=@0xbfbfe4a8, aXBLBaseTag=0) at nsCSSFrameConstructor.cpp:7166 #59 0x29279e7b in nsCSSFrameConstructor::ConstructFrame (this=0x883b200, aPresShell=0x87edc00, aPresContext=0x883a400, aState=@0xbfbfe4e0, aContent=0x88dbf40, aParentFrame=0x88e9194, aFrameItems=@0xbfbfe4a8) at nsCSSFrameConstructor.cpp:7022 #60 0x2927d47b in nsCSSFrameConstructor::ContentAppended (this=0x883b200, aPresContext=0x883a400, aContainer=0x88dbb00, aNewIndexInContainer=2) at nsCSSFrameConstructor.cpp:8238 #61 0x28c42340 in StyleSetImpl::ContentAppended (this=0x8835700, aPresContext=0x883a400, aContainer=0x88dbb00, aNewIndexInContainer=2) at nsStyleSet.cpp:1442 #62 0x29222102 in PresShell::ContentAppended (this=0x87edc00, aDocument=0x85a6800, aContainer=0x88dbb00, aNewIndexInContainer=2) at nsPresShell.cpp:5154 #63 0x28be3fef in nsDocument::ContentAppended (this=0x85a6800, aContainer=0x88dbb00, aNewIndexInContainer=2) at nsDocument.cpp:1890 #64 0x28ad1cc5 in nsHTMLDocument::ContentAppended (this=0x85a6800, aContainer=0x88dbb00, aNewIndexInContainer=2) at nsHTMLDocument.cpp:1338 #65 0x28ac98d9 in HTMLContentSink::NotifyAppend (this=0x888de00, aContainer=0x88dbb00, aStartIndex=2) at nsHTMLContentSink.cpp:4780 #66 0x28ac0463 in SinkContext::CloseContainer (this=0x87ce600, aNode=@0x88380e8) at nsHTMLContentSink.cpp:1560 #67 0x28ac49b7 in HTMLContentSink::CloseContainer (this=0x888de00, aNode=@0x88380e8) at nsHTMLContentSink.cpp:3419 #68 0x28844f0c in CNavDTD::CloseContainer (this=0x88e6000, aNode=0x88380e8, aTarget=eHTMLTag_td, aClosedByStartTag=0) at CNavDTD.cpp:3558 #69 0x28844fb0 in CNavDTD::CloseContainersTo (this=0x88e6000, anIndex=5, aTarget=eHTMLTag_td, aClosedByStartTag=0) at CNavDTD.cpp:3594 #70 0x2884526a in CNavDTD::CloseContainersTo (this=0x88e6000, aTarget=eHTMLTag_td, aClosedByStartTag=0) at CNavDTD.cpp:3750 #71 0x288429cc in CNavDTD::HandleEndToken (this=0x88e6000, aToken=0x89517d0) at CNavDTD.cpp:1999 #72 0x288408e9 in CNavDTD::HandleToken (this=0x88e6000, aToken=0x89517d0, aParser=0x8781900) at CNavDTD.cpp:898 #73 0x2883f82f in CNavDTD::BuildModel (this=0x88e6000, aParser=0x8781900, aTokenizer=0x8839880, anObserver=0x0, aSink=0x888de00) at CNavDTD.cpp:521 #74 0x288555db in nsParser::BuildModel (this=0x8781900) at nsParser.cpp:2005 #75 0x28855340 in nsParser::ResumeParse (this=0x8781900, allowIteration=1, aIsFinalChunk=1, aCanInterrupt=1) at nsParser.cpp:1871 #76 0x2885475c in nsParser::ContinueParsing (this=0x8781900) at nsParser.cpp:1495 #77 0x28b00909 in CSSLoaderImpl::Cleanup (this=0x8858500, aKey=@0xbfbfec08, aLoadData=0x8839e80) at nsCSSLoader.cpp:798 #78 0x28b010a6 in CSSLoaderImpl::SheetComplete (this=0x8858500, aSheet=0x0, aLoadData=0x8839e80) at nsCSSLoader.cpp:908 #79 0x28b01292 in CSSLoaderImpl::ParseSheet (this=0x8858500, aIn=0x8593220, aLoadData=0x8839e80, aCompleted=@0xbfbfeccc, aSheet=@0xbfbfecd0) at nsCSSLoader.cpp:942 #80 0x28b014c5 in CSSLoaderImpl::DidLoadStyle (this=0x8858500, aLoader=0x8852180, aStyleData=0x8530520, aLoadData=0x8839e80, aStatus=0) at nsCSSLoader.cpp:979 #81 0x28b0070e in SheetLoadData::OnStreamComplete (this=0x8839e80, aLoader=0x8852180, aContext=0x0, aStatus=0, aStringLen=3992, aString=0x884e000 "A:active {\n color:", ' ' <repeats 13 times>, "#800000;\n\ttext-decoration: none;\n}\n\nA:hover {\n color:", ' ' <repeats 13 times>, "#800000;\n\ttext-decoration: underline;\n}\n\nA:link {\n color:", ' ' <repeats 13 times>, "#0000FF;\n\ttext-decor"...) at nsCSSLoader.cpp:733 #82 0x2873d754 in nsStreamLoader::OnStopRequest (this=0x8852180, request=0x88e2300, ctxt=0x0, aStatus=0) at nsStreamLoader.cpp:161 #83 0x2873cbf1 in nsStreamListenerTee::OnStopRequest (this=0x8150a40, request=0x88e2300, context=0x0, status=0) at nsStreamListenerTee.cpp:24 #84 0x28775f40 in nsHttpChannel::OnStopRequest (this=0x88e2300, request=0x87a5504, ctxt=0x0, status=0) at nsHttpChannel.cpp:2566 #85 0x2872a2b1 in nsOnStopRequestEvent::HandleEvent (this=0x87f0b40) at nsRequestObserverProxy.cpp:212 #86 0x28729a2c in nsARequestObserverEvent::HandlePLEvent (plev=0x87f0b40) at nsRequestObserverProxy.cpp:115 #87 0x281f88bd in PL_HandleEvent (self=0x87f0b40) at plevent.c:590 #88 0x281f87c5 in PL_ProcessPendingEvents (self=0x814bd00) at plevent.c:520 #89 0x281f98f7 in nsEventQueueImpl::ProcessPendingEvents (this=0x8144620) at nsEventQueue.cpp:388 #90 0x28dc3ac7 in event_processor_callback (data=0x8144620, source=6, condition=GDK_INPUT_READ) at nsAppShell.cpp:184 #91 0x28dc37f6 in our_gdk_io_invoke (source=0x81d4420, condition=G_IO_IN, data=0x81d4410) at nsAppShell.cpp:77 #92 0x283f05e4 in g_io_unix_dispatch () from /usr/local/lib/libglib12.so.3 #93 0x283f1c8b in g_main_dispatch () from /usr/local/lib/libglib12.so.3 #94 0x283f22b4 in g_main_iterate () from /usr/local/lib/libglib12.so.3 #95 0x283f244c in g_main_run () from /usr/local/lib/libglib12.so.3 #96 0x283127f7 in gtk_main () from /usr/X11R6/lib/libgtk12.so.2 #97 0x28dc4070 in nsAppShell::Run (this=0x814a870) at nsAppShell.cpp:364 #98 0x28d945da in nsAppShellService::Run (this=0x811e580) at nsAppShellService.cpp:308 #99 0x8050e2f in main1 (argc=1, argv=0xbfbff3fc, nativeApp=0x80880c0) at nsAppRunner.cpp:1350 #100 0x80517f0 in main (argc=1, argv=0xbfbff3fc) at nsAppRunner.cpp:1698

Pav, any ideas on this one?

Just for the record, I don't think I've ever crashed clicking no on a confirmation dialog, at least I can't remember a no followed by a crash.

I also eventually crash with Linux 0.9.9 after saying yes to a lot of images. TB4253672H Stephend, could you please retrieve this? Thanks.

Diego, can you try this on the trunk, please? Thanks.

Ok, so I crashed once after clicking no on several images, but there was one dialog box that I had clicked yes on that had not yet disappeared. I'm only guessing here, but it may have been waiting for the image to load, then crashed while rendering, allowing me to click no on several more dialogs.

> Diego, can you try this on the trunk, please? Thanks. My pleasure. It does also crash with Linux 2002032008, but does not trigger talkback, although I did install the xpi.

I have a similar problem with gamespy.com's screenshot viewer, except the conformation dialogs are unlimited, and I can't close moz without endtasking mozilla.exe.

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

Thanks to Germano from the bug I just duped, we now have a 100% reproducible way to crash mozilla. (Edited slightly): 1. start fresh, virgin mozilla 2. go to URL about: 3. select Edit > Preferences 4. select Privacy & Security > Images 5. Click on 'Manage Image Permissions' 6. Click on 'Remove all sites' 7. Click on OK 8. Set 'Accept all Images' 9. Set 'Ask me before downloading an image' 10. Click 'OK' 11. goto http://www.cnn.com/ 12. you will be asked about 5 times whether you want to load images from site X. Say 'no' always, and also remember the decision. 13. Goto Edit > Preferences > Security & Privacy > Images 14. Click on 'Manage Image Permissions'. You see 4 or 5 sites. 15. Click on 'remove all sites' 16. click on 'ok' 17. click on ok of the preferences dialogue also (mozilla might not actually try to load things until you scroll .. so after you close the preference screen, try to scroll down) 18. mozilla will now instantly try to reload things, and give you a confirm pop-up. For me it usually is 'The site toolbar.netscape.com wants to load an image...' 19. Say no, and remember the decision. 20. Say hello to the talkback agent.[mozilla just crashed]

crash using above steps (100% reproducible) the stack trace is mostly the same as the other ones in this bug

Changing QA Contact

I'm not sure why this is an RDF bug? It looks from the stack trace to be a crash in the image code called from the table code...

Although bug #57188 (http://bugzilla.mozilla.org/show_bug.cgi?id=57188) is marked as related to cookies, a lot of the text in there deals with crashes during image confirmation dialogues. Should the two be duplicates? Also, #110268 (see comment #6) really very much looks like this one. There seem to be several intertwined issues, all leading to crashes around image loading confirmation dialogues: 1) Multiple confirmation dialogues popping up at the same time, leading to a crash. 2) Closing pop-up's before answering the dialogue -> Crash 3) Having duplicate dialogues for seemingly the same thing and ansering no -> Crash 4) Reloading the page with cleared 'image permission manager' -> Crash Could one easy fix be to make the dialogue stop further loading / processing of a page? I guess you call it 'modal dialogue box'. That way, nobody can pull away allocated data structures from under its seat. Having one pop-up at the time would also be nice for usability reasons.

I meant bug #110269. Sorry.

I was able to reproduce the crash by visiting cnn.com. And well, this is just more layout re-entrancy due to the content sink forcing a flush on us. In fact, I got a stack that included _nested_ flushes! (IOW, one flush caused us to re-enter the event queue, which caused us to bring up a the image dialog, which caused us to dispatch another focus event, which caused another flush...all nested in the same activation!) I think we're just going to have to tell the content sink to shove it where the sun don't shine if we've got any frame construction activity happening on the stack: no amount of deferred view creation is going to save us in this case (cf. bug 134437).

This pretty much renders the feature useless.

I'm still crashing, even with the patches from bug 134437. The basic problem with this bug is that this feature is taking layout to places that it wasn't designed to go. In the short term, I'd recommend disabling this feature altogether until we can either redesign layout to accomodate the feature, or redesign the feature to accomodate layout.

Okay, I'll be nice. I won't trap people who have already set this pref.

Chris: Could bug 133633 be related to this one? Maybe even a dup?

Comment on attachment 82524 [details] [diff] [review] okay, no gun either. seems quite reasonable to me. sr=alecf can you post to n.p.m.seamoney or .general about this, just so people understand this is a technical limitation, and nothing to do with the conspiracies are required to run AOLTW?

Comment on attachment 82524 [details] [diff] [review] okay, no gun either. r=morse

Fix checked in on trunk.

Is there an advocacy bug that I can vote for to restore the "ask image" preference?

As the original reporter, I'm rejecting this fix. I can accept disabling as a temporary work around, but Image blocking has been around for far too long to be backed/commented out and forgotten about. I don't see why/how confirming for images is any different or more difficult than confirming for cookies.

There are other ways to Rome. Why not inform users about this limitation, instead of removing the confirmation window? This piece of code has been sitting in the tree for over a long time now, so why remove it now? Why didn't you limited the number of confirmations? Wait and see what you get in return: "Are you absolutely sure this has nothing to do with AOL?" Trust me!

Are you absolutely sure this has nothing to do with AOL?

Read Chris' comment. He gave a perfectly valid reason for this change. If you think this is an AOLTW conspiracy, then feel free to redesign the necessary components of mozilla so that you can do things like image confirmations in a more 'ideal' way.

Backing out a magnet feature without a proper debate is IMHO tantamount to sabotaging Mozilla. This feature was one of the reasomn I swithed to Mozilla 100%. I do not think I will test a new build (past 5/14) for a long time, now :-(

I'm sorry, but "this feature is taking layout to places that it wasn't designed to go" does not explain anything. Please, give us the ugly details. Not providing them will only add to the belief that this IS the big thumb of AOLTW.

If the image confirmation popup is indeed severely broken, at the least we need an alternate way of editing image blocking. Actually I would prefer to add image sites to the block list manually rather than dealing with the popup all the time. And, what about cookie confirmation? How is it different from image confirmation? I haven't tried it, but is it broken too?

You can still block images by right-clicking on them, or by going to the tools->image-manager menu. It's hard for me to believe that people are really blocking images by setting the warn-me pref and getting numerous popups on every site they visit. The cookie warning box is different than the image-warning box because accepting a cookies doesn't involve layout.

Why is it that so hard to believe? In general, I like to have images displayed. However, when I'm reading my SPAM infested webmail, I don't want images loaded because in many cases they include a unique id in the image URL. That is, I don't want them to "validate" my email address so they can sell it off to someone else giving me more SPAM in my mail box. So, I use the popup to ask me if I want to load images. When browsing the web normally, I always allow image loading and click the box to always allow from the server. Since I frequent the same sites, I hardly ever get bothered with the popup (pretty much only when following links from slashdot stories or when sites use akamai with their random server names). When reading my webmail, I always deny and click the box so that I'm always denying from the server. That's because the mail is most likely SPAM and I don't want to encourage them to continue sending me SPAM by informing them I've just read their mail.

Yes, you can block some images by using the context menu, but you aren't going to be able to block the 1x1 images that way. You also can't tell what server you are blocking from the context menu, "Am I blocking server 1, content server 1, ad-server 1, or ad-server 2?" If users are going to be forced to do image blocking through some other method, please consider enhancements requested in bugs 110075 and 110093.

Read the stack traces, stop mouthing moronic conspiracy suspicions. I take as revisionist and conspiratorial a view of history as any sane person I know, but this is ridiculous! /be

> It's hard for me to believe that people are really blocking images by setting the > warn-me pref and getting numerous popups on every site they visit. (comment 46) As someone has mentioned, I think that a lot of people use the popup the way I did: by checking the "remember this decision" box, you only get the popup once for any given site. Thus the popup lets you filter sites as they come in, which is my preferred mode of using image permissions. That being said, I certainly understand wanting to disable the popup if it's causing a lot of crashes (it's crashed me once or twice). And it's a little farfetched to think that this is the Great AOLTW Conspiracy. But can we have a bug for fixing and reenabling this feature, so I and like-minded people can vote for it, and so we can dupe bugs against it? If people want I can file the bug.

This bug is the only major problem I have with Mozilla. I could have avoided the crashes by changing my image handling preferences, but like the others who have commented, I only want those images I've specifically oked. So I have no idea why this would be an AOL conspiracy (?!) but I'd be really annoyed if that image handling option were removed. (I say "no" almost all the time, so even better for me would be an option that blocked all images except from sites marked as "allowed" - then I'd just turn that on by hand when wanted.) Danny.

Thinking about this some more, the image handling options are confusing. There should be four options under "Image Acceptance" -- "never load", "always load", "load only if in allowed list", and "load unless in denied list". (I'm not sure about "from the originating server": possibly image permissions should be based on the domain of the sourcing page rather than, or as well as, the image server, but that's getting too complicated.) And the "Ask me before downloading an image" option should probably be labelled something like "ask about permissions when encountering a new site". This is not directly related to this bug, of course, but if we're still considering changing how image handling is done at this stage... Danny.

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

I always surf with image permissions turned on (and I wish they worked for email too, but that's bug 97055). I'm not sure why people find this hard to believe; as mentioned in comment 47, I generally click the "remember this decision" checkbox, so I quickly build up a list of "trusted" sites which can load images. I have filed numerous talkbacks regarding bug 133633 (which was recently marked a dup of this bug). This bug is the major crasher for me by far, and the proposed fix is rather distasteful (more of a fix by amputation). Can we have a little more detail on the "taking layout to places that it wasn't designed to go" comment (comment 31)? Where should I look to learn more about this?

I'm with Brian on this. I wouldn't mind losing the "ask me before downloading an image" option provided there was a "load images only if allowed" option in the acceptance policy. Then I could browse with that set, and manually toggle image acceptance for sites where I want images. If it's not feasible to add extra options "load ONLY IF allowed" and "load UNLESS denied", how about changing the behaviour of "Do not load any images" and "Accept all images" so they do that? After all, if the user enables images from a particular site, they presumably mean that to override "no images" if they have that set, and similarly with blocking specific sites and allowing all images... The options would then be "Do not load any images (unless site is allowed)" and "Accept all images (unless site is blocked)" - and you could lose the "originating server" and "ask me" options. That would be much simpler, but would offer functionality I want that the current setup doesn't. I'm now using Mozilla 90% of the time - I've almost weaned myself off Netscape 3.04, which is my other choice of browser (it's solid as a rock with Javascript and Java disabled). But I don't think I would use Mozilla at all without some site-specific image-permissions - I simply DO NOT want images from most sites (I'm using a 33k modem but prefer text even with 100Mbps ethernet at work), but they are occasionally worth loading and some sites aren't usable without them.

In bug 133633, danm raises the workaround of using a native widget for this. That would be fine with me. Another option that has been suggested that *might* avoid the problem is to queue confirmations and make sure no more than one is displayed at the same time. Maybe that would even allow to keep the window and just hide it when dismissed, and unhide/raise when needed again. Visual cues tell me that the crash only happens when two dialogs are visible at the same time. I still think at least the gtk crash has to do with not keeping track of the ownership of the offscreen, but I haven't worked out the ownership model of Mozilla :-( On my list of things to try is to record in the object whether or not we own the offscreen and not free it when the nsRenderingContextGTK object is destroyed, but I got sinking feelings when I read that the Windows port is also affected by this. Still, it would at least help me in learning about the ownership model :-)

I just added my vote as another person who "really blocks images by setting the warn-me pref and getting numerous popups". Like comment 47 says, image blocking is the ONLY reasonable way to read webmail.

I'm another person who would like to use this feature constantly...the minor hassle of clicking ok or deny the first time i visit a site is completely outweighed by the benefits of having precise interactive control over what images (and cookies...i use that feature as well) are displayed. I see this problem multiple times per day on both windows and linux with RC2. I have also noticed that this only seems to happen when multiple confirm dialog boxes are coming up simultaneously.

I tracked down the problem to pages with background images (at least I haven't found a different reason when I was looking for the cause). Whenever a page wants to load a background image and that page is not listed in the can/cannot load images list and I am asked wether to load it, mozilla crashes if I permit mozilla to load this picture. No other image (except for a background image) is needed to reproduce the crash, and one popup is enough - there is no need for multiple ones. I've set up a page, that only contains a background image for easy reproduction: 1. use a build where the option to "ask before accepting images" is still usable 2. allow mozilla to load images from the originating server only 3. set the checkbox to ask before downloading images 4. make sure "fachschaft.informatik.hu-berlin.de" is not in your can/cannot load images list 5. goto http://fachschaft.informatik.hu-berlin.de/mozilla_crashtest.html 6. say yes (check "remember this decision" box)on the popup 7. mozilla usually crashes. If not, remove the domain from the image permission list and hit reload. And yes, I want to have that feature back again, too.

Instead of posting me too comments please vote for this bug (some of you still haven't voted for this bug!) and rally up some more votes on irc, at mozillazine and in the newsgroups. If this bug gets 50 or more votes, it will get on the driver's radar and hopefully get fixed for 1.0.

This won't make 1.0 no matter what, it's too late (rc3 is about to ship, and we'd like that candidate to become 1.0 without a respin, ideally). Voting also doesn't help fix the underlying problem, or deliver up extra hackers to help. Drivers can only persuade so much. The best thing would be for someone who knows the code and its control flow to come up with a patch. /be

Sheesh. You jokers have spent too many late nights with the Lone Gunmen. Quitcher whining and write some code, already. If you'd like to implement this feature properly, here's what to do. 1. For each image that is being loaded, check to see if it has been allowed, denied, or if the user must intervene. If the image is allowed to load, load it. If the image may not be loaded, do nothing (i.e., don't issue a load request). 2. If the user must intervene, do the same thing you do in the `deny' case, but place the image's URL on a queue, and return out to the main event loop. (The important thing is to _not_ nest an event loop while doing frame construction or reflow!) 3. At some later point, process the queue. This could be done in any number of ways. You could post an event in (2) that would bring up the same crappy dialog that was popping up before (which would be insanely stupid from a design point of view). Or, you could bring up a `image manager' dialog that lists all the pending image loads and lets a user accept or deny each individually. Go nuts. design an ultra geeky UI that lets you organize the image loads into a tree by source URL. Or by page loading them. Have a `deny all' button. Whatever. 4. When a user decides to `accept' an image, queue the image load. Now, _I_ am not going to implement this, as I find this feature to be inane. But now at least all you conspiracy theorist whiners have a flashlight with which you may now be able to find your ass.

Don't worry Chris, I'm going to unassign you and hand a helpwanted sign.

Just because you think the feature is "inane" doesn't mean the rest of the world agrees with you.

Please file a new bug to implement this feature. This bug is about a _crash_.

As requested, bug 146513 opened.

Yow. Chris, on behalf of the whiners like myself who don't have 10% of the necessary skill to touch Mozilla's code, I want to apologize for any and all comments that pissed you off so much. You've put in a lot of hours, and it's appreciated. That said, this bug is about a crash _when using image confirmation_. Closing the bug by shutting off the feature ... really, come on now. On a different note, it seems like this should be dependency-connected (or duped) with bug 107806 and bug 110269 one way or another, since they will probably be fixed (or not) simultaneously.

verified fixed with win2k build 20020523.. no blocking-> no crash

Adding [@ libgdk-1.2.so.0 | libX11.so.6 - nsRenderingContextGTK::FillRect] to summary from bug 133633 for future reference (those are the stack signatures this crash was being reported under by Talkback). With this feature disabled, we should no longer see those crashes.

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

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

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

Comment on attachment 82524 [details] [diff] [review] okay, no gun either. This caused a regression: bug 147841

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

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

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

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

I want Mozilla to ASK me "before" loading an image. If I have it set to Allow, the image will allways load the image from the server before I can block it. If I have it set to Block, I will never be able of unblocking that image, because it will not be displayed! And the menu option (Tools|Image Manager|Block/Unblock...) only refers to the main page. If there are images from other server on that page you will not be able to block them! I understand it was a buggy feature, but... what about those who actually WANT/NEED this feature? If it is still buggy, those who don't want it, may simply not use it! Please, get the "Ask before loading an image" option back!!!

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

the patch for trunk was checked in. this is a patch for branch, the minor additional changes will avoid the issue referenced in Comment #73.

Comment on attachment 94473 [details] [diff] [review] patch for 1.0 branch Carrying forward r/sr. Approved for 1.0 branch. Change mozilla1.0.1+ to fixed1.0.1 when checked in. Please do so ASAP

Comment on attachment 94473 [details] [diff] [review] patch for 1.0 branch checked into branch

I hope the patch will not disable the image blocking in mail-news, which is a very important spam block feature ?

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

verified1.0.1

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

How about popping up a single dialog box that has a list of all the image sites referenced by the current page (at least those not already blocked or approved) with a block/allow (remember) line item next to each one? Then leave the dialog open until all images are loaded/blocked. This would allow only one dialog box per page, but it would stay open until all images have been filtered. Something like this: Images on this page: Allow: ( )All ( )None (x)Selective (enables list below) Site Allow/Disallow Remember Images on Page ===================================================================== www.cnn.com (x)Allow ( )Disallow [x] 13(details) ads.doubleclick.net ( )Allow (x)Disallow [x] 2(details) cnn.com (x)Allow ( )Disallow [ ] 10(details) (OK) (Disabled until all sites have a selection for Allow/Disallow) Selecting All or None would take the action and dismiss the dialog. Details would list the images for that site.

Sean, this discussion seems to have moved to bug 146513. I've copied your comment to there (BTW, I really like this UI) and added you to the CC list (I hope you don't mind).

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

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