Build: Mozilla M11 (1999111520) System: WinNT SP5 with 64 MB RAM. The download dialog does not pop when a '.exe', '.zip', etc. link is clicked from a frame of a multi-frame page. Test Case: ----------- Go to http://www.cpam.freeserve.co.uk/, click on the 'download' link on the left. The right frame will show links to download enzip260.exe and 401comupd.exe. However, if you click on any of the links, the downlooad dialog (Unknown file type, Open..Save..Cancel) does not appear. Instead, the console shows the following message: DocLoaderFactory: Unable to create ContentViewer for command=view, content-type=application/octet-stream. However, if you go directly to http://www.cpam.freeserve.co.uk/download/ (single frame) and click on the link, the download works fine.

Confirmed exactly as reported with current M12 build. Clicking on links to .exe or .zip files brings up "Unknown file type" dialog from which file can be saved if the link occurs on its own page, but not if the same page is loaded into a frame. Instead, the following appears in the console: >DocLoaderFactory: Unable to create ContentViewer for command=view, >content-type=application/octet-stream >Error: Can't load: http://www.cpam.freeserve.co.uk/download/enzip260.exe >(80004005) Tested with: 1999-11-28-08-M12 nightly binary on Windows NT 4.0sp3 Changing component from "Browser-General" to "XPApps"

Updating QA contact.

Wow, not sure how to start here. hyatt?

...

This appears to be some sort of quirk in the docloader (or equivalent). I'll look into it more with the debugger later and figure out what to do. It will likely be reassigned at that point but I can investigate further before pawning it off. I'm setting to M13 for now.

This is getting to nsWebShell::DoContent for the inner webshell. That method wants to pass it to its docloader observer. But, the docloader observer (the browser instance) is attached to the *outer* webshell. I spoke to Travis, he says this is being overhauled and to reassign to mscott.

I have a fix for this. We are trying to invoke the unknown content handler from the webshell for the inner frame. But it doesn't have a document loader observer on the inner frame so it can't reach the unknown content handler. The fix is too ask the parent webshell for the unknown content handler. I'm attaching the patch here. Normally I'd ask rick potts to review this but he's out of town...=( I'll try to find someone else.

adding warren to the cc list as I'm hoping to get the code review from him.

I got Seth to review this for me so I could check it in before the tree closes today. This is now fixed.

tested w/winNT comm bits from 2000-020108. the dialog appears fine now, and i don't get "Error: can't load" msgs... however, i still see the following line appear in the console: DocLoaderFactory: Unable to create ContentViewer for command=view, content-type=application/octet-stream oh, downloading works fine --i'm just wondering what the above msg means...

verif on linux blocked by bug 26249.

joyfully verifying. used opt comm bits (for all 3 platforms) from 2000021708.