76534 - [xpcdom] ftp site persist in later browsed sites

Status: VERIFIED FIXED

(SeaMonkey :: General, defect)

Description

[Tracy Walker [:tracy]]

seen on [xpcdom] build

-browse a few pages then browse the above ftp site...then browse onto a few more 
pages
the ftp site briefly flashes in the browser window before each page is loaded

-now click on the grippy to open the sidebar.
the ftp site pops up in the browser window (reload brings up the proper page)
the same will happen if you close the sidebar.

Comment 1

[John Bandhauer]

I see this with file: urls too. On NT (at least) iconizing the main window and 
bringing it back up will cause the wrong page to draw...

- load file:///c|/temp
- load www.cnn.com
- iconize main window
- restore main window

I see: c:\temp directory listing draw and then the animated gifs of the cnn site 
draw over them. Moving the mouse causes links in the cnn site to redraw. 
Iconizing and bringing the window up does it all again.

Comment 2

[Nisheeth Ranjan]

jband, I don't see ftp sites persisting in later browsed sites in the latest 
XPCDOM builds.  The binary I'm using is available at 
http://ozone.mcom.com/~jst/xpcdom-win-20010427.zip.  Would you please try to 
reproduce this on your build and provide an update?  Thanks!

Comment 3

[Johnny Stenback (:jst)]

John, maybe my theory about this being due to *something* leaking in the older
builds? :-)

Comment 4

[John Bandhauer]

I still see this and worse. With the steps I described above...

On the trunk it consistently does this persisted window thing

On the xpcdom branch however, It fails with an unrecoverable assert in the JS 
engine. It is the dreaded attempt to call js_AllocGCThing while gc is running. 
see bug 52859. There is another bug (that I can't find) having to do with this 
same sort of call back into js_AllocGCThing during gc having to do with focus 
events when windows get destroyed (on Windows).

I'm not sure if this is really connected as a clue to the persistence thing 
or not. Nevertheless, it is a real problem. In non debug builds this should 
just cause a failure to create a wrapper (because the js_NewObject call that 
causes the js_AllocGCThing call will return failure). There is no telling what 
specific result this has on the running of the browser from then on.

I'll attack a stack trace.

Comment 5

[John Bandhauer]

Attachment: stack of failure due to call to js_AllocGCThing during gc

Comment 6

[John Bandhauer]

Looking closer at my stack the focus msg is the things happening here. 

Ah! This is bug 71515. The fix to make it not crash was checked into the trunk:

-r1.282 of nsDocShell.cpp on Apr 27 04:17

So, it is not on our branch yet.

But, like I said, is see the persistence thing on the trunk. So when we get the 
fix above on the branch to not make it crash, I'm betting the persistence thing 
will, um, persist.

Comment 7

[Tracy Walker [:tracy]]

I no longer see this behavior wiht the latest builds

http://ozone.mcom.com/~jst/xpcdom-opt-20010430.tar.gz (Linux) 
http://ozone.mcom.com/~jst/xpcdom-mac-opt-20010430.sit (Mac) 
http://ozone.mcom.com/~jst/xpcdom-win-opt-20010501.zip (Windows) 

Comment 8

[Johnny Stenback (:jst)]

Great! Marking FIXED.

Comment 9

[Tracy Walker [:tracy]]

verified