From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.3+) Gecko/20010903 Netscape6/6.1b1 BuildID: 20010903 After dragging in multiple images into composer the browser and composer became unstable. I went to http://www.hobbyvalley.com/gm/gm.html and dragged some of the box art images into the composer window. After dragging in about four of the pictures composer would not let me browse the page I was editing. Also the browser started acting funny, whenever I clicked on a link nothing would happen. When I moved the mouse after clicking on a link then the stop button and throbber would disappear. If I put the pointer where the stop button should be then it would reappear and I could click on stop. Reproducible: Always Steps to Reproduce: 1.Open Netscape Browser 2.Open Comopser 3.Switch to the browser window and make it small enough to see the composer window in the background. 4.Go to http://www.hobbyvalley.com/gm/gm.html 5.click on one of the box art links and drag the image into composer and close the image pop up window. 6.Repeat step 5 until you have 5 images in the window 7.Click on the browse button in the toolbar and save the changes. Actual Results: The page never comes up once you click on the browse button. If you close out of Netscape completely (browser and composer) then the program will still be in the task list even though you do not see it open. This problem does not happen with a lot of large image files that are local, only with image files that are loaded from the web. Expected Results: I would expect that the browser and composer would not become unstable because of the pictures being added to the document.
Confirmed in 9-10 build
Can you clarify a little here? When I go to the indicated URL I only see one image. Are you clicking in turn on each of the items on the left, then dragging the image that appears? And I need a clarification on dragging, like: how are you doing it? If I click on the image and drag, I get a selection in the browser window; the image doesn't drag (I didn't know we supported image D&D, thought that had been LATERed). Is there some trick to it? Or is this a platform-parity issue? (in which case, we'll either need to find some other way to reproduce this problem, or it needs to go to someone who works on a platform where they can reproduce this).
What I am doing is clicking on the link to bring up the pop-up window and then single clicking on the image and dragging the image to the composer window. For example: Click on the first link in the list which is "WING W-GUNDAM 0 ZERO CUSTOM 1/144" and then click on the image in the pop-up window one time and then drag it to the composer window. After that you close the pop-up window and repeat with the next link which would be "TALLGEESE III (Three) 1/144". After that go down the list of links for about 5 images total and repeat the steps, then the browser and composer should be unstable at that point.
Thanks for the explanation! What happened to me was that after I had inserted 4 of the images, when I clicked on the fifth link to get the fifth popup window (I'd been dismissing all the earlier popups) before clicking on the next link), the browser hung and the popup window never appeared. I killed the app, and the stack said this: #0 0x40645cb4 in __poll (fds=0x8536c00, nfds=4, timeout=9) at ../sysdeps/unix/sysv/linux/poll.c:63 #1 0x40460485 in g_main_poll () from /usr/lib/libglib-1.2.so.0 #2 0x4045fdca in g_main_iterate () from /usr/lib/libglib-1.2.so.0 #3 0x404600ee in g_main_iteration () from /usr/lib/libglib-1.2.so.0 #4 0x40c6abce in nsAppShell::DispatchNativeEvent (this=0x8b7aa10, aRealEvent=0, aEvent=0x0) at nsAppShell.cpp:386 #5 0x408494a6 in nsXULWindow::CreateNewContentWindow (this=0x8184150, aChromeFlags=1678, aDocShellTreeItem=0xbfffd048) at nsXULWindow.cpp:1387 #6 0x4084881c in nsXULWindow::GetNewWindow (this=0x8184150, aChromeFlags=1678, aDocShellTreeItem=0xbfffd048) at nsXULWindow.cpp:1267 #7 0x40840fb5 in nsContentTreeOwner::GetNewWindow (this=0x852c908, aChromeFlags=1678, aDocShellTreeItem=0xbfffd048) at nsContentTreeOwner.cpp:216 #8 0x407968b5 in nsWindowWatcher::OpenWindowJS (this=0x814d7a0, aParent=0x84f47a4, aUrl=0x8b0fd20 "gmimg/ew4c.jpg", aName=0x8b29cc8 "pp", aFeatures=0x89ac6f8 "resizable=1,status=yes,scrollbars=1,width=620,height=440, top=1, left=1", aDialog=0, argc=0, argv=0x0, _retval=0xbfffd4d8) at nsWindowWatcher.cpp:549 #9 0x40796007 in nsWindowWatcher::OpenWindow (this=0x814d7a0, aParent=0x84f47a4, aUrl=0x8b0fd20 "gmimg/ew4c.jpg", aName=0x8b29cc8 "pp", aFeatures=0x89ac6f8 "resizable=1,status=yes,scrollbars=1,width=620,height=440, top=1, left=1", aArguments=0x0, _retval=0xbfffd4d8) at nsWindowWatcher.cpp:437 #10 0x4155d1b3 in GlobalWindowImpl::OpenInternal (this=0x84f47a0, aUrl=@0xbfffd688, aName=@0xbfffd5e8, aOptions=@0xbfffd548, aDialog=0, argv=0x0, argc=0, aExtraArgument=0x0, aReturn=0xbfffd870) at nsGlobalWindow.cpp:3190 #11 0x41558e80 in GlobalWindowImpl::Open (this=0x84f47a0, _retval=0xbfffd870) at nsGlobalWindow.cpp:2326 #12 0x401e6368 in XPTC_InvokeByIndex (that=0x84f47a8, methodIndex=13, paramCount=1, params=0xbfffd870) at xptcinvoke_unixish_x86.cpp:138 #13 0x40966230 in XPCWrappedNative::CallMethod (ccx=@0xbfffd940, mode=CALL_METHOD) at xpcwrappednative.cpp:1952 #14 0x4096e8a6 in XPC_WN_CallMethod (cx=0x84f4910, obj=0x8499620, argc=3, argv=0x8ca9ce4, vp=0xbfffdae0) at xpcwrappednativejsops.cpp:1254 #15 0x400874f8 in js_Invoke (cx=0x84f4910, argc=3, flags=0) at jsinterp.c:807 #16 0x40095228 in js_Interpret (cx=0x84f4910, result=0xbfffe08c) at jsinterp.c:2719 #17 0x40087582 in js_Invoke (cx=0x84f4910, argc=1, flags=0) at jsinterp.c:824 #18 0x40095228 in js_Interpret (cx=0x84f4910, result=0xbfffe6e0) at jsinterp.c:2719 #19 0x40087c9a in js_Execute (cx=0x84f4910, chain=0x8499620, script=0x89ab570, down=0x0, special=0, result=0xbfffe6e0) at jsinterp.c:989 #20 0x4005c4b4 in JS_EvaluateUCScriptForPrincipals (cx=0x84f4910, obj=0x8499620, principals=0x86d0bb8, chars=0xbfffe7c8, length=23, filename=0x0, lineno=0, rval=0xbfffe6e0) at jsapi.c:3315 #21 0x415497a7 in nsJSContext::EvaluateString (this=0x84f4898, aScript=@0xbfffe7b0, aScopeObject=0x8499620, aPrincipal=0x86d0bb4, aURL=0x0, aLineNo=0, aVersion=0x0, aRetValue=@0xbfffe8b0, aIsUndefined=0xbfffe8c8) at nsJSEnvironment.cpp:622 #22 0x420132ba in nsJSThunk::EvaluateScript (this=0x8a03078) at nsJSProtocolHandler.cpp:243 #23 0x420146bc in nsJSChannel::AsyncOpen (this=0x8ccfb38, aListener=0x8bbe738, aContext=0x0) at nsJSProtocolHandler.cpp:559 #24 0x40c0f039 in nsDocumentOpenInfo::Open (this=0x8bbe738, aChannel=0x8ccfb38, aCommand=7, aWindowContext=0x852cca0) at nsURILoader.cpp:183 #25 0x40c1089a in nsURILoader::OpenURIVia (this=0x81ccf00, channel=0x8ccfb38, aCommand=7, aWindowContext=0x852cca0, aLocalIP=0) at nsURILoader.cpp:530 #26 0x40c10655 in nsURILoader::OpenURI (this=0x81ccf00, channel=0x8ccfb38, aCommand=7, aWindowContext=0x852cca0) at nsURILoader.cpp:491 #27 0x4145e219 in nsDocShell::DoChannelLoad (this=0x852cca0, aChannel=0x8ccfb38, aLoadCmd=7, aURILoader=0x81ccf00) at nsDocShell.cpp:4814 gdb-internal-error: virtual memory exhausted: can't allocate 4072 bytes. Internal GDB error: recursive internal error. #28 0x4145da68 in nsDocShell::DoURILoad (this=0x852cca0, ... and then gdb went into an apparent infinite loop (or maybe it was trying to dump core) and I had to kill it to get control of my machine back.
I tried this with a page full of thumbnails, and I easily inserted all the thumbnails without any problem. So I'm guessing it has to do with the cumulative size of all the images (possibly an imagelib memory leak?) The indicated page's images are large for inlined images, but they're not excessively huge by the standards of web images. I don't know what to do with this bug. It's certainly not a composer issue. I doubt it's even a backend issue; more likely somewhere like imagelib or content. But how do we pin it down to figure out who owns the problem?
This must be something in the way we're storing images. The editor doesn't store any persistent image data.
Assuming nobody's seen this crash in 8 years, resolving as WORKSFORME. Please re-open if you can reproduce this behavior on a recent release.