Closed Bug 110112 Opened 23 years ago Closed 22 years ago

Crash after long sequence of image confirmations - [@ libgdk-1.2.so.0 | libX11.so.6 - nsRenderingContextGTK::FillRect]

Categories

(Core :: Layout, defect, P1)

Product:
Core
Component:
Layout
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: mythdraug, Unassigned)

References

(
URL
)

Details

(Keywords: crash, regression, topcrash)

Crash Data

Attachments

(3 files, 3 obsolete files)

Diego's crash stack
1.89 KB, text/plain
Details
stack trace
18.90 KB, text/plain
Details
humourous stack trace
48.59 KB, text/plain
Details 
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.
Severity: major → critical
Keywords: crash
Summary: [Crash] crash after long sequence of image confirmations → Crash after long sequence of image confirmations
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
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 (?)
Assignee: asa → harishd
Component: Browser-General → Parser
QA Contact: doronr → moied
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
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
verified WFM with build ID 20020110 on win2k
Status: RESOLVED → VERIFIED
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
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
The stack points to rendering. 

--> Kevin.
Assignee: harishd → kmcclusk
Status: REOPENED → NEW
Component: Parser → RDF
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?
Assignee: kmcclusk → pavlov
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.
Attached file Diego's crash stack — 
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]
Attached file stack trace — 
crash using above steps (100% reproducible)
the stack trace is mostly the same as the other ones in this bug
Changing QA Contact
Assignee: pavlov → waterson
QA Contact: moied → tever
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.
Attached file humourous stack trace — 
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.
Status: NEW → ASSIGNED
Component: RDF → Layout
Priority: -- → P1
Target Milestone: --- → mozilla1.0
Target Milestone: mozilla1.0 → mozilla1.0.1
Depends on: 134437
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.
Attached patch okay, no gun either. (obsolete) — — Splinter Review 
Okay, I'll be nice. I won't trap people who have already set this pref.
Attachment #82511 - Attachment is obsolete: true
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?
Attachment #82524 - Flags: superreview+
Comment on attachment 82524 [details] [diff] [review]
okay, no gun either.

r=morse
Attachment #82524 - Flags: review+
Blocks: 144093
Fix checked in on trunk.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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!
Blocks: 57188
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.
Keywords: helpwanted, mozilla1.0, regression
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.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Don't worry Chris, I'm going to unassign you and hand a helpwanted sign.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Just because you think the feature is "inane" doesn't mean the
rest of the world agrees with you.
Assignee: waterson → nobody
Status: REOPENED → NEW
Please file a new bug to implement this feature. This bug is about a _crash_.
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
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.
Summary: Crash after long sequence of image confirmations → Crash after long sequence of image confirmations - [@ libgdk-1.2.so.0 | libX11.so.6 - nsRenderingContextGTK::FillRect]
Keywords: topcrash
*** 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. ***
Attached patch patch for 1.0 branch (obsolete) — — Splinter Review 
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.
Attachment #82524 - Attachment is obsolete: true
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
Attachment #94473 - Flags: superreview+
Attachment #94473 - Flags: review+
Attachment #94473 - Flags: approval+
Comment on attachment 94473 [details] [diff] [review]
patch for 1.0 branch

checked into branch
Attachment #94473 - Attachment is obsolete: true
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. ***
Blocks: 146513
verified1.0.1
Keywords: 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).
Keywords: fixed1.0.1, helpwanted
*** Bug 167129 has been marked as a duplicate of this bug. ***
*** Bug 137593 has been marked as a duplicate of this bug. ***
Crash Signature: [@ libgdk-1.2.so.0 | libX11.so.6 - nsRenderingContextGTK::FillRect]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: