1) Find a link to a file that Mozilla can't handle. 2) Right click on it, select "Open in New Window". 3) New window opens, spawns download dialog. 4) Download starts, new window sticks around without any content. If a newly-opened window turns out to hold undisplayable content, spawning a download window, then the new browser window should be closed.
Verified at http://www.google.com/search?hl=en&q=pdf+mozilla on Win98.
That's very sensible indeed. I'm not sure how it could be implemented, though. Could we hold new window creation until we got the server MIME type? I doubt it. Gerv
No, "open in new window" should create a new window instantaneously. There are too many issues associated with delaying window creation, in any case. I'd say the appropriate thing to do is close the window if we can't display the MIME type. One way to accomplish this would be to close the current window if there is no window history and we can't display the selected type.
In bug 70501, it was wrote: Note that with mailto:, the extra browser window should never be opened, but with .zip files served through http, the browser window has to be created and then destroyed.
[Aufbau-P5]: I run into this whenever I think a thumbnail is for an image when it's really for a realplayer movie. Fortunately, not many porn videos are in realplayer format, and their thumbnails are usually distinguishable from those for large images.
I'm really not sure this is a good idea. Consider the possibility that you have new windows set to open your home page, and one day your home page accidentally gets changed to a MIME type which Mozilla doesn't recognize ... Unless you were on a Mac, then whenever you started up Mozilla it would put up a download dialog and then quit.
Just program this function so that all new windows that download MIME types close automatically, unless that new window is the only Mozilla browser window open.
Andrew, that makes no sense. *Everything* that can be downloaded, including HTML, has a MIME type.
Ack. You are right, of course. Let me respond again to comment 7 with a proposed solution. If new window spawns a download dialog, close the new window, except if the new window is the only Mozilla browser window open. This would resolve the issue of the home page being set to something that spawns the download dialog, which would put Mozilla in an endless loop. It would also resolve the situation where Joe User opens a link in a new window, which opens a download dialog. Thinking he has the new window open, Joe User, for whatever reason, closes his original window *before* the new window opens. In this situation, Joe User expects a browser window to be open. With my proposed solution, above, Mozilla would meet that expectation.
-> file handling From dup bug 136945: this also happens with "open link in new tab".
*** Bug 136945 has been marked as a duplicate of this bug. ***
*** Bug 173110 has been marked as a duplicate of this bug. ***
This happens when trying to download / open a PDF file. A blank window opens, then the PDF reader activates, and the creates a 2nd new window to display the PDF document in. This doesn't happen with 1.2.1
When user select "Open in new window" or "in new tab", it seems more logical that Mozilla opens that window or tab, as requested. But when I click on a ZIP file with left button, Mozilla does open a new blank window, then the Save dialog. That window remains there. EXE files does not produce this effect. I use Mozilla for a long time now, and I think this behavior is new.
I agree with comment #15. If I tell Mozilla to open some unsupported format in a new window (or tab) and I end up with a blank window, then that's my problem. But if I just left click on some link (pdf files for example) then it should just open that file in Acrobat and not create an additional useless blank window.
*** Bug 229318 has been marked as a duplicate of this bug. ***
*** Bug 234772 has been marked as a duplicate of this bug. ***
http://forums.mozillazine.org/viewtopic.php?p=428099 Cusser has written an extension which solves a portion of this problem. Something like this could be part of the solution.
*** Bug 246141 has been marked as a duplicate of this bug. ***
now there is a bug for Firefox, see bug 251140
*** Bug 282345 has been marked as a duplicate of this bug. ***
How much does this relate to new tabs/windows being opened for download links and installing new extensions, in general? Whenever I click download links a new blank tab is loaded with the download dialogue, and the same goes for clicking install for extensions. Its a nitemare, there is literally no need for this, or anything else like it mentioned here for that matter. Are there other bugs relating to this, and is the being seriously looked at, because it doesnt have for other browsers, so it really does need fixing, there's no need for it, no use, it only causes annoyance and confusion to users.
*** Bug 317762 has been marked as a duplicate of this bug. ***
(In reply to comment #20) > http://forums.mozillazine.org/viewtopic.php?p=428099 > > Cusser has written an extension which solves a portion of this problem. > Something like this could be part of the solution. This works most of the time, but hasn't been updated in a long time.
Is this something that should be fixed or should this be resolved wontfix?
This problem seems to be fixed in Firefox 2.0b2 - but only when you left click on a download link that opens in a new tab/window. When you middle click it still leave an extra tab/window.
On the trunk anyway, I see blank windows on occasion still.
I replied cuz I had a user ask me about this in #firefox and I still got the empty tab on a direct link to mms://....wmv. When I'm back on that machine I'll look up the link. Test case is WFM though. (bon echo nightlies)
(In reply to comment #27) > Is this something that should be fixed or should this be resolved wontfix? I am seeing MORE blank windows lately with 2.0 nightly builds.
Definitely still happens in firefox 2, at least when middleclicking on a link that turns out to be a PDF or other non-internal mime type. Is this bug a dup (or vice versa) of bug 346561?
Bug is still reproducible in Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16.