When you DL a file that Mozilla doesn't know what to do with, you can choose to open it with a certain application. If the path to that application is too long, it can become impossible to click the "Cancel" or "OK" buttons because they scroll off the dialog box. Steps to reproduce: 1. Go start DLing the latest nightly from the Mozilla.org front page. Try another platform so you get the "Downloading blah.zip" dialog. 2. Instead of clicking "OK", click "Choose...". 3. Select a path to a program or file (doesn't have to be an application even) that's several folders deep (~7 should do it). 4. Click "Open" or whatever your platform has you click to get out of the dialog. 5. Notice that the "Cancel", "OK" and possibly "Choose..." buttons are no longer visible. What happens: If your path is too long and contains no spaces, the "OK", "Cancel" and "Choose..." buttons disappear off the right side of the dialog. If your path is too long and contains spaces, the text wraps... But the OK and Cancel buttons still move off the bottom of the dialog. In OS X there's some redraw issues too... You can see parts of where the buttons used to be, but not all of them. And those parts don't represent the buttons anymore, so they aren't clickable. You need to press Cmd-. to dismiss the dialog What should happen: We could do several things, but I guess the best idea would be to resize the dialog if the contents won't fit any more. (Truncating the path would be a hassle and who knows what the right way to do it would be.) In the case of a path that has no spaces, it would be a good idea to wrap it so the "Choose..." button doesn't get lost too. Perhaps wrapping at a directory delimiter would be acceptable.

Same occurance in this 200112608 build.. since the window is not resizeable, and the OK button is shoved to the right, it falls off the edge of the window and is not clickable, as per screenshot.

dup *** This bug has been marked as a duplicate of 112180 ***

mass verification of duplicate bugs: to find all bugspam pertaining to this, set your search string to "DuplicateBugsBelongInZahadum". if you think this particular bug is *not* a duplicate, please provide a compelling reason, as well as check a recent *trunk* build (on the appropriate platform[s]), before reopening.