98389 - Composer becomes unstable after dragging multiple pictures from the browser into the document.

Status: RESOLVED WORKSFORME

(Core :: Graphics: ImageLib, defect)

Description

[TucsonTester2]

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.

Comment 1

[Kathleen :Brade]

-->akkana

Comment 2

[James Baxter]

Confirmed in 9-10 build

Comment 3

[Akkana Peck]

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).

Comment 4

[TucsonTester2]

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.

Comment 5

[Akkana Peck]

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.

Comment 6

[Akkana Peck]

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?

Comment 7

[Akkana Peck]

This must be something in the way we're storing images.  The editor doesn't
store any persistent image data.

Comment 8

[Bobby Holley (:bholley)]

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.