STEPS TO REPRODUCE: 1) On non-Windows, find a file type that doesn't have a default OS handler for it. On Windows, find a file type with an "executable" extension. 2) Set up a preferred handler for it (no idea how one does this in the Firefox UI, sorry). 3) Set the type to prompt. 4) Try to open a file of that type that's served as application/octet-stream. (Not sure you need all those, but those should guarantee that you reproduce the problem.) EXPECTED RESULTS: Get a dialog where you can choose to save the file or open with your preferred app from step 2. ACTUAL RESULTS: Get a dialog where you can only save the file. This is effectively a regression from the fix for bug 347230. Gavin says the goal is to show the "simple" UI if there is no choice other than "save". The code as written also shows the "simple" UI if the choices are "save" and "use preferred app". NOTE: Personally, I think that if we have no way to handle the file we should allow the user to select an application in addition to offering the "save" option. That's what we do on Windows, for files that are not "executable"; I'm not sure why we're not doing that on other platforms. Perhaps this should be a separate bug, and I'm a little afraid of getting involved in helper apps UI stuff again. ;)

(In reply to comment #0) > 1) [...] On Windows, find a file type with an "executable" extension. > [...] > Gavin says the goal is to show the "simple" UI if there is no choice other > than "save". The code as written also shows the "simple" UI if the choices > are "save" and "use preferred app". Under Windows, do you imagine a preferred app for a .EXE file? I think "Save" is the only reasonable recourse for that particular type. If this is a bug only on non-Windows platforms, why give the Windows option in step 1? Note that some other files -- especially and irritatingly, Visio .VSD files (bug 280847) -- are considered "executable," I guess because they have macro support, so they get tarred with the same brush -- even tho macro-running Word documents are treated as normally as JPEGs. I think the fix for this is to remove .VSD from the list of "executables" rather than changing the way EXEs are handled. And now, a bit of OT kvetching: > 2) Set up a preferred handler for it (no idea how one does this in the > Firefox UI, sorry). That's because it can't be done (nor in Thunderbird). It's a bigger problem in TB because you are sending files as attachments, and without being able to define the MIME type's association, you're kind of stuck with sending them as "application/octet-stream", just like the bad guys do.

> Under Windows, do you imagine a preferred app for a .EXE file? No, but what does that have to do with it? isExecutable() doesn't just flag .exe files. I can certainly imagine a preferred app for the following (non-exhaustive, since we flag 71 extensions as executable so I just skimmed the list) extensions: "asp", "bat", "vbs". A text editor, to be exact. Oh, and we've been considering adding "pl" and "pm" to this list, because otherwise Perl gets run by ActiveState for some users. Again, a text editor might be nice here. And no matter what you say about "vsd", "bat" should for sure remain in the list of executables. I'm not going to argue the "vsd" thing because quite frankly I don't care about the exact list of extensions; I care about the UI working well for users no matter what this list is.

The regressing bug was not checked into the 1.8.0 branch, so we don't want to "fix" it there. --> gavin, can this be fixed safely in a security release? Provisionally blocking 1.8.1.4 for now, but will be one of the first to get bumped.

Gavin and I just talked about the "set up preferred handler" step. Slightly expanded steps would be: * Load a .foo file of type application/foo (that is "executable" on Windows or doesn't have an OS handler on other OSes). * In the resulting dialog, set up a preferred handler for it by clicking the "Open with" button and picking an app. * Load a .foo file of type application/octet-stream to see this bug.

Talked a bit more with Boris about this. While I can reproduce the issue described in comment 0/comment 4, the behavior from before the patch for bug 347230 was no better - the "full" dialog appeared, but the "Open with" option was greyed out. This means that there is no functional regression due to the patch for bug 347230. Given that, I don't think this should block (and I don't really know that a fix would be suitable for the branch at all, so I question wanted1.8.1.x too).

As I understand it, this case, prior to the change to the simpler dialog we just disabled open with and the remember checkbox, which has zero functional difference. Not going to block on this.

For what it's worth, just because it's not a functional regression from our previous broken release doesn't mean it's not broken. I guess I don't care that much whether you fix this or not, since I'm not using the app... but fixing this is a definite improvement in the user experience, imo.

Requesting wanted-firefox3 for this.

Just wanted to note that we're getting rid of the "extended" UI with the "Open with" option disabled in bug 556369. That interface was a leftover from bug 347230, that appeared only in very rare cases. That change still has no functional difference from the current behavior, but is a step towards making the dialog's logic clearer.