found this on NT using today's 1999120908 build. will check on other platforms... 1. go to above URL, which should start Paintshop Pro downloading. it doesn't, so... 2. click the "click here" link to start downloading the file. result: Unknown File Type dialogs appears over and over again. occaisionally i can get in and select a save location and the file will download. but the dialogs keep on appearing. only way to stop is to quit mozilla. expected: the dialog should appear only once. here's what appears in the console each time a File Type Dialog appears: nsLayoutHistoryState::AddState OOPS!. There was already a state in the hash tabl e for the key Error: Can't load: http://www3.jasc.com/pub/psp60ev.exe (804b0002) DocLoaderFactory: Unable to create ContentViewer for command=view, content-type= application/octet-stream Document: Done (0.328 secs) WEBSHELL+ = 20 JavaScript Error: ReferenceError: onUnload is not defined

if there's more than one browser win open, closing the downloading page does stop the dialogs, so in that case i don't need to completely quit mozilla.

yup, occurs on linux (1999120911) and mac (1999120910) as well. on linux it seg faulted and sent Talkback incident 2147999. here's the trace, but am unsure how relevant it is... Trigger Reason: SIGSEGV: Segmentation Fault: (signal 11) Call Stack: (Signature = 0x08854920 60291408) 0x08854920 libraptorhtml.so + 0x17d312 (0x40b47312) libraptorhtml.so + 0x17d359 (0x40b47359) libraptorhtml.so + 0x17d359 (0x40b47359) libraptorhtml.so + 0x17d359 (0x40b47359) libraptorhtml.so + 0x17d359 (0x40b47359) libraptorhtml.so + 0x17d359 (0x40b47359) libraptorhtml.so + 0x17d359 (0x40b47359) libraptorhtml.so + 0x17d359 (0x40b47359) libraptorhtml.so + 0x17d359 (0x40b47359) libraptorhtml.so + 0x17d359 (0x40b47359) libraptorhtml.so + 0x17d359 (0x40b47359) libraptorhtml.so + 0x17d359 (0x40b47359) libraptorhtml.so + 0x17d359 (0x40b47359) libraptorhtml.so + 0x17d359 (0x40b47359) libraptorhtml.so + 0x1963db (0x40b603db) libraptorhtml.so + 0x2e0eef (0x40caaeef) libraptorhtml.so + 0x219aae (0x40be3aae) libraptorhtml.so + 0x214ce8 (0x40bdece8) libraptorhtml.so + 0x210e09 (0x40bdae09) libraptorhtml.so + 0x2124a0 (0x40bdc4a0) libraptorhtmlpars.so + 0x1c757 (0x40d7e757) libraptorhtmlpars.so + 0x1ce0a (0x40d7ee0a) libraptorhtmlpars.so + 0x1cecf (0x40d7eecf) libraptorhtmlpars.so + 0x1cfa8 (0x40d7efa8) libraptorhtmlpars.so + 0x1a1a6 (0x40d7c1a6) libraptorhtmlpars.so + 0x23c50 (0x40d85c50) libraptorhtmlpars.so + 0x24629 (0x40d86629) libraptorhtmlpars.so + 0x24de4 (0x40d86de4) libraptorwebwidget.so + 0xea1f (0x40867a1f) liburiloader.so + 0x23fe (0x4052b3fe) libraptorwebwidget.so + 0xf0d6 (0x408680d6) libnecko_http.so + 0xcb3f (0x41083b3f) libnecko.so + 0xae30 (0x40492e30) libnecko.so + 0xa8c0 (0x404928c0) libplds3.so + 0x1c17 (0x40113c17) libplds3.so + 0x1b86 (0x40113b86) libxpcom.so + 0x60304 (0x400f2304) libwidget_gtk.so + 0x21ab7 (0x404fbab7) libwidget_gtk.so + 0x2167d (0x404fb67d) libglib-1.2.so.0 + 0xe3ca (0x4068e3ca) libglib-1.2.so.0 + 0xfa86 (0x4068fa86) libglib-1.2.so.0 + 0x10041 (0x40690041) libglib-1.2.so.0 + 0x101e1 (0x406901e1) libgtk-1.2.so.0 + 0x8b7a9 (0x405b97a9) libwidget_gtk.so + 0x21f05 (0x404fbf05) libnsappshell.so + 0x11532 (0x40452532) mozilla-bin + 0x25d5 (0x0804a5d5) mozilla-bin + 0x2859 (0x0804a859) libc.so.6 + 0x17cb3 (0x401f8cb3)

Putting on the PDT+ radar.

Reassigning to mscott after PDT meeting, since it looks unrelated to evaughns work.

Sarah, I take it file downloading is completely broken, not just certain file types?

File downloading works fine for many ftp sites. I use it to downoad the next day's seamonkey bits all the time. The problem is isolated to this web page (and maybe similar web pages) that run a JS script to load the ftp url. That combined with the fact that when you click on the mentioned link in the document (that uses an anchor #Foo which we have bugs saying we don't work very welll with) results in this bug. But file download by itself works fine. this bug isn't related to certain file types but to the way the web page is trying to download the .exe

updated summary to clarify the issue (since it doesn't affect *all* file downloads). should this still remain as PDT+...?

probably not, the way to check, BTW, is to remove the PDT+, so PDT team looks again. If you are absolutely positive, then you can remove the DOGFOOD and PDT+.

does this happen only with this page OR with every page on download.com?

no, not all, just some unknown percentage. I tried three other apps and they were fine. Cnet does some screwy stuff.

Putting on PDT- radar.

Marked blocker, so let's start with M13. That ok with you, Scott?

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

It's not just C|Net. I have some software updates at a site I manage that are called similarly. A click on the link to #foo does a window.open() and that window has a refresh containing the URL to the file via FTP. Mozilla pops the dialog in this case as well. Sorry I can't make the files public as they are software updates for paying customers only. But, I wanted to verify that it is not just C|Net doing weird stuff.

We had some extremely similar problems back when I was testing SmartDownload. The stub would either balk/hesitate at the start, start looping with a starting of download or fail with one of a dozen obscure error numerical dialog messages. We never had a good test case, but I'd be willing to try and piece one together for this. Q: While I haven't looked at this part of source yet, is there any of the NetZip folks code in the latest release? Or how we moved on... Jim Race

added vimages@well.com to cc: list

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

mscott : See also bug #22734 in which the BODY .onload() is apparently being called repetitively when it should only be called once. (Possibly, but not necessarily, a similar code path). Simple test case from bug #20587 for download.com, this problem: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=3864

It is no longer limited to FTP url's loaded from a JS. Directly clicking on a link at Netscape's FTP to download Communicator throws this dialog with 2000012415.

Putting dogfood in the keyword field.

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

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

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

nominating for beta1...since it didn't get fixed for M14. also updated the URL since it's moved. still a problem using today's bits [2000.03.01] on winNT --as well as linux and mac. updating platform info, too.

when i tried quitting seamonkey on winNT today (using the close widget), i crashed and got the following talkback report: http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=46&cp=1&ck1=SUser+email+address&cd1=%25sairuh%40netscape%2Ecom%25&co1=like&bbid=6135306 Trigger Type: Program Crash Trigger Reason: Access violation Thread ID: Call Stack: (Signature = ntdll.dll + 0xce0c (0x77f6ce0c) a85fbaba) ntdll.dll + 0xce0c (0x77f6ce0c) ntdll.dll + 0x7546 (0x77f67546) js_LockScope1 [d:\builds\seamonkey\mozilla\js\src\jslock.c, line 649] js_LockObj [d:\builds\seamonkey\mozilla\js\src\jslock.c, line 720] js_GetSlotWhileLocked [d:\builds\seamonkey\mozilla\js\src\jslock.c, line 276] js_ValueToFunction [d:\builds\seamonkey\mozilla\js\src\jsfun.c, line 1663] JS_ValueToFunction [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 493] nsJSContext::CallEventHandler [d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 542] nsJSDOMEventListener::HandleEvent [d:\builds\seamonkey\mozilla\dom\src\events\nsJSDOMEventListener.cpp, line 97] nsEventListenerManager::HandleEventSubType [d:\builds\seamonkey\mozilla\layout\events\src\nsEventListenerManager.cpp, line 700] nsEventListenerManager::HandleEvent [d:\builds\seamonkey\mozilla\layout\events\src\nsEventListenerManager.cpp, line 1255] nsXULElement::HandleDOMEvent [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULElement.cpp, line 3079] nsXULElement::HandleDOMEvent [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULElement.cpp, line 3068] nsXULElement::HandleDOMEvent [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULElement.cpp, line 3068] nsXULElement::HandleChromeEvent [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULElement.cpp, line 4132] GlobalWindowImpl::HandleDOMEvent [d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 369] nsWebShell::OnEndDocumentLoad [d:\builds\seamonkey\mozilla\webshell\src\nsWebShell.cpp, line 2670] nsDocLoaderImpl::FireOnEndDocumentLoad [d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 592] nsDocLoaderImpl::DocLoaderIsEmpty [d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 494] nsDocLoaderImpl::OnStopRequest [d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 438] nsLoadGroup::RemoveChannel [d:\builds\seamonkey\mozilla\netwerk\base\src\nsLoadGroup.cpp, line 545] nsLoadGroup::Cancel [d:\builds\seamonkey\mozilla\netwerk\base\src\nsLoadGroup.cpp, line 218] nsDocLoaderImpl::Stop [d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 204] nsURILoader::Stop [d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 602] nsDocShell::Stop [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 971] nsWebShell::Stop [d:\builds\seamonkey\mozilla\webshell\src\nsWebShell.cpp, line 2012] nsWebShell::Destroy [d:\builds\seamonkey\mozilla\webshell\src\nsWebShell.cpp, line 3376] nsHTMLFrameInnerFrame::~nsHTMLFrameInnerFrame [d:\builds\seamonkey\mozilla\layout\html\document\src\nsFrameFrame.cpp, line 452] nsHTMLFrameInnerFrame::`scalar deleting destructor' nsFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrame.cpp, line 411] nsFrameList::DestroyFrames [d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp, line 36] nsContainerFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 98] nsFrameList::DestroyFrames [d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp, line 36] nsContainerFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 98] nsBoxFrame::Destroy [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 2629] nsFrameList::DestroyFrames [d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp, line 36] nsContainerFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 98] nsBoxFrame::Destroy [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 2629] nsFrameList::DestroyFrames [d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp, line 36] nsContainerFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 98] nsBoxFrame::Destroy [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 2629] nsFrameList::DestroyFrames [d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp, line 36] nsContainerFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 98] nsBoxFrame::Destroy [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 2629] nsFrameList::DestroyFrames [d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp, line 36] nsContainerFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 98] nsFrameList::DestroyFrames [d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp, line 36] nsContainerFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 98] ViewportFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp, line 140] FrameManager::~FrameManager [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 343] FrameManager::`scalar deleting destructor' FrameManager::Release [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 331] PresShell::~PresShell [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 720] PresShell::`scalar deleting destructor' PresShell::Release [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 662] nsCOMPtr_base::~nsCOMPtr_base [d:\builds\seamonkey\mozilla\xpcom\base\nsCOMPtr.cpp, line 50] DocumentViewerImpl::~DocumentViewerImpl [d:\builds\seamonkey\mozilla\layout\base\src\nsDocumentViewer.cpp, line 388] 0xc18b60c7

The problem of crashing on all "unknown file type dialogs" is already fixed (bug 29360). So this bug deals _only_ with JS called downloads, correct? Does the problem still exist?

this is a different problem from bug 29360. this particular one still does occur on all platforms. does PDT still regard this as pdt-, or could it be upgraded? it's dogfood and blocks downloading from sites such as cnet.com...

I removed the PDT- so they will look at it again

Try downloading Winamp from http://www.winamp.com. I can't even get it to do anything. The code on the page to start the download is: <!-- function downloadsAllUpInYerFace() { window.location = "ftp://ftp.netscape.com/pub/blind/partner/winamp/wa26_lite.exe"; } --> If you go there with M14 final, nothing happens at all.

PDT+

Hmmm this is going to be tricky. The problem is that when we fire the on end document load in the webshell for the document url, we are told by the JS on load handler to laod a ftp url. This url gets run inside the current window. So when it's done we fire an OnEndDocumentLoad call. But the original http document is still loaded in the webshell is still there so we end up firing it's on load handler again. This of course causes us to load another ftp url and the proces repeats. We can't just not fire the onload event if the document url doesn't match the url we are running because then we'll bring loading documents which contain multiple urls in them.

I'm still working on this. The fix is going to be really hard. In fact I haven't thought of a fix yet that won't break something else. =)

no longer investigating, we have a plan of attack.

Okay I have a fix for this now. The code change is simple but the risk factor is high as I'm alterting code which effects when we signal the onload notification and an end of document webshell notification for a url. We need more risk analysis before I conclude that this is the right fix for this problem.

I checked in the fix for this.

yay! verif w/opt comm bits on winNT and linux, as well as opt mozilla bits on mac [2000.03.07.09].

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

Changing all Progress Window components to XP Apps: GUI Features. The Progress Window component will be retired shortly.

Mass removing self from CC list.

Now I feel sumb because I have to add back. Sorry for the spam.