found this using today's linux comm bits, 2000-02-02-09 (today's win and mac comm bits not yet available). not a problem before... to repro: attempt to bring up the "Unknown file type" dialog by entering a url to a .exe/.zip file, eg: ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/jre122.exe http://www.palmgear.com/software/redirector.cfm/psaver.zip?prodID=3376&type=zip before the dialog has a chance to appear, seamonkey crashes. here's the console output: change lock icon to unlock - new document DocLoaderFactory: Unable to create ContentViewer for command=view, content-type=application/octet-stream Document: Done (0.49 secs) WEBSHELL+ = 4 change lock icon to unlock - new document failed to set the page title. Error loading URL ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/jre122.exe change lock icon to unlock - new document ! nsSecureBrowserUIImpl found: chrome://directory/content/directory.xul change lock icon to unlock ?(chrome 80004005) data.contentType = application/octet-stream

reassigned qa contact to me. added keywords.

Uh oh ...

jud says this might be related to 20576 note: if you enter the full url including filename (or click on the link below), it does a keyword search on the ftp server name This appears to be linux only problem

PDT+

Putting dogfood in the keyword field.

Looks like the same Linux redirection via JS bug. *** This bug has been marked as a duplicate of 21358 ***

no, this is a different issue, imho. this bug [alas] occurs at more sites, thus more frequently. moreover, the effects differ from bug 21358: in this bug, seamonkey crashes before the Unknown File Type dialog even has a chance to appear. reopening.

I think this is fixed. You can't easily verify due to bug 26607.

Why has this been re-opened?

my fault, I opened a new bug an apparently accidentally reopened this one.

i still crash when attempting to download the following, so reopening. http://www.palmgear.com/software/redirector.cfm/psaver.zip?prodID=3376&type=zip i'll attach the talkback report soon. here's what i see in the console: WEBSHELL- = 4 WEBSHELL- = 3 DocLoaderFactory: Unable to create ContentViewer for command=view, content-type=application/x-zip-compressed Document: Done (4.424 secs) WEBSHELL+ = 4 Failed to set the page title in history Error loading URL http://www.palmgear.com/software/redirector.cfm/psaver.zip?prodID=3376&type=zip --------INITIAL REFLOW-------- *** 0x866153c computedHgt: 1073741824 Reason: Initil*** 0x866153c computedHgt: 1210 Reason: Initil*** 0x866153c computedHgt: 1210 Reason: Initildata.contentType = application/x-zip-compressed *** 0x866153c computedHgt: 1210 Reason: Resize*** 0x866153c computedHgt: 1210 Reason: Resize*** 0x866153c computedHgt: 1210 Reason: Resize*** 0x866153c computedHgt: 1210 Reason: Resize*** 0x866153c computedHgt: 1073741824 Reason: Initil*** 0x866153c computedHgt: 775 Reason: Increm areaHgt: 670

h'm, i just read law's remark that bug 26607 would make verification of this tough --but would that bug still cause downloading on linux to crash seamonkey? just wondering... [re-resolve if that's the case.]

talkback report info... http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=20&cp=1&ck1=SUser+email+address&cd1=%25sairuh%40netscape%2Ecom%25&co1=like&bbid=5187667 Trigger Type: Program Crash Trigger Reason: SIGSEGV: Segmentation Fault: (signal 11) Call Stack: (Signature = nsFieldSetFrame::Reflow() 1363ce25) nsFieldSetFrame::Reflow() nsBoxFrameInner::FlowChildAt() nsBoxFrameInner::FlowChildren() nsBoxFrame::Reflow() nsBoxFrame::Reflow() nsContainerFrame::ReflowChild() RootFrame::Reflow() nsContainerFrame::ReflowChild() ViewportFrame::Reflow() nsHTMLReflowCommand::Dispatch() PresShell::ProcessReflowCommands() HandlePLEvent() PL_HandleEvent() PL_ProcessPendingEvents() nsEventQueueImpl::ProcessPendingEvents() event_processor_callback() our_gdk_io_invoke() libglib-1.2.so.0 + 0xe52a (0x4069e52a) libglib-1.2.so.0 + 0xfbe6 (0x4069fbe6) libglib-1.2.so.0 + 0x101a1 (0x406a01a1) libglib-1.2.so.0 + 0x10341 (0x406a0341) libgtk-1.2.so.0 + 0x8c209 (0x405c7209) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x181eb (0x402191eb)

btw, had tested this w/today's comm bits, 2000-02-10-08.

that's a separate bug, bug 27239 marking this as fixed, but can't verify until the others are fixed this bug is ftp specific, the other bugs are not

thx, paulmac... so, essentially i'm blocked from verifying this one due to bug 27239...

Boy, if I could get a nickel for every file download problem, I'd be a rich man. *This* problem is fixed! I swear. The problem is that every time sairuh goes and tries to verify it, Mozilla *still* crashes. But for a different reason (almost each and every time!). There are (at least) 2 separate problems for which there are not fixes (to my knowledge): 26607 - Width of unknown content dialog is screwed. You get a wide dialog on Windows, random strangeness (most often terminating in a crash) on Linux, and unknown on Mac. This bug makes it hard to deal with *any* file download bug since normally you get to the downloading by way of the unkown-content dialog. There is a way to bypass that dialog: You can right-click on a link to the file you want to download and can then chose "Save link as..." on the context menu. 27239 - Mr. Valeski opened this new bug this morning. The unknown-content dialog crashes upon display due to some box resize/layout bug. That's what sairuh witnessed this morning, I believe. Needless to say, this will hinder efforts to fix 26607 and efforts to verify any of the multitude of "file download crashes" type bugs (I think I've got 3 PDT+ ones in my own personal list of bugs). So that's my spin on things. I suggest we try to narrow the focus of these bugs so we have a prayer of ever getting them resolved and verified. For this bug, I'd suggest that we attempt to do the save-link-as via context-menu trick on the sweetlou URL mentioned in the bug description (and which I've placed in the bug's URL field). If that download succeeds, we close this bug, once and for all. When (not if) file download breaks again, we'll open a new and different bug that addresses the problem du jour specifically. So that's my plan. If my Linux build can get that file from sweetlou, I'm going to resolve this FIXED one more time.

Sorry, I just overwrote some changes due to a midair collision (I was in such a ranting mood after entering all that that I was in no mood to try to navigate the bugzilla maze to preserve things). OK, I just successfully downloaded jre122.exe! The bad news is that closer reading of this bug leads me to think that it was originally written to address a problem with the unknown content dialog. So never mind :-). This bug appears to pre-date the dialog sizing problem (26607) so I can't say for sure that fixing that will fix the problem that prompted this bug). But it seems fair to say that they won't be able to fix the sizing problem without making the dialog actually appear on Linux and once that's working, I'll bet it will appear on Linux when you got to either of these particular URLs. So I'm going to clear the FIXED resolution and leave it officially in "blocked by 26607" state.

I opened this bug with a 2/10 Linux build and clicked on the first link in the initial bug report. A beautiful "unknown content" dialog appeared. The second link seems to be no longer valid (I got a timeout error).

i can download from ftp now on linux [2000-02-14-08 comm bits], so am verifying this. if other problems with ftp downloads crop up, pls open a new bug and cc me. thx!