Note: There are a few cases of duplicates in user autocompletion which are being worked on.

"Open in New Window" -> download or helper app leaves extra blank window




File Handling
16 years ago
4 months ago


(Reporter: vectro, Unassigned)


(Blocks: 3 bugs)

Firefox Tracking Flags

(Not tracked)



(1 attachment)



16 years ago
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.

Comment 1

16 years ago
Verified at on Win98.
Ever confirmed: true
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.


Comment 3

16 years ago
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.


16 years ago
Blocks: 70501

Comment 4

16 years ago
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.

Comment 5

16 years ago
[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.
Whiteboard: [Aufbau-P5]


16 years ago
Whiteboard: [Aufbau-P5]

Comment 6

16 years ago
Created attachment 62199 [details]

Comment 7

16 years ago
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.

Comment 8

16 years ago
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.

Comment 9

16 years ago
Andrew, that makes no sense. *Everything* that can be downloaded, including
HTML, has a MIME type.

Comment 10

16 years ago
Ack. You are right, of course. Let me respond again to comment 7 with a proposed

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.

Comment 11

16 years ago
-> file handling

From dup bug 136945: this also happens with "open link in new tab".
Assignee: mpt → law
Component: User Interface Design → File Handling
QA Contact: zach → sairuh
Summary: "Open in New Window" -> Download, should close window → "Open in New Window" -> download or helper app leaves extra blank window

Comment 12

16 years ago
*** Bug 136945 has been marked as a duplicate of this bug. ***
QA Contact: sairuh → petersen

Comment 13

15 years ago
*** Bug 173110 has been marked as a duplicate of this bug. ***

Comment 14

15 years ago
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

Comment 15

14 years ago
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.

Comment 16

14 years ago
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.

Comment 17

14 years ago
After reviewing this bug report and my own thoughts on this issue, I agree with
comment 10, however, this should also apply to tabs when using any form of
"Single Window Browsing". As Single Window Browsing is not a core feature yet, I
would assume that this would be difficult to cope with as yet, and so this may
be more realistic for one of the later milestone builds.

The only other feasible solution would be to hardwire extensions into the client
and force it to not open a new window simply because of "_blank" being specified
as a target. I don't know whether this breaks standards or not, someone more
knowledgeable can comment if they wish, but before everyone gets up in arms
about it, let me elaborate.

1) Very few filetypes are downloaded or viewed regularly where this is a common
problem. I would guess that only a handful of binary extensions would really be
necessary to solve this problem for the masses (such as .exe, .zip, .rar, .pdf)

2) Extensions not included do not prevent the correct action being taken based
on MIME type.

3) For occasions where the incorrect extension is used for the MIME type sent:
The browser would simply not open a new window by default for target="_blank"
links. Example, although a little extreme, would be HTML being sent as text/html
and .exe with _blank as the target. Mozilla/Firebird would see .exe and _blank
and refuse to open a new window. HTML is, however, displayed. I would say that
this is a website/server evangelism issue rather than a browser bug, but I think
people will disagree with me about this. In any case, it's extremely unlikely to

4) Example 2, maybe more realistic? I don't know... a binary download
application/rar (or whatever the MIME is) being sent as the correct MIME, but as
.txt: Mozilla/Firebird reads .txt and _blank and decides that it can open a new
window or tab. It then realises that it's actually a binary (from the MIME type
sent) and acts accordingly by downloading the file/whatever you have specified
within the download manager.

5) Worst case scenarios are:
  a) In extremely rare cases a file that should be loaded in _blank loads in _self
  b) Types not included generate a blank new tab or new window (this happens anyway)

6) I believe that target="_blank" is deprecated in favour of using
rel="external" and related javascript to cope with external linking.

Comment 18

14 years ago
*** Bug 229318 has been marked as a duplicate of this bug. ***

Comment 19

14 years ago
*** Bug 234772 has been marked as a duplicate of this bug. ***

Cusser has written an extension which solves a portion of this problem.
Something like this could be part of the solution.


13 years ago
Blocks: 241972
Flags: blocking1.8a2?

Comment 21

13 years ago
*** Bug 246141 has been marked as a duplicate of this bug. ***


13 years ago
Flags: blocking1.8a2? → blocking1.8a2-

Comment 22

13 years ago
now there is a bug for Firefox, see bug 251140


13 years ago
Blocks: 208817
*** Bug 282345 has been marked as a duplicate of this bug. ***

Comment 24

12 years ago
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.

Comment 25

12 years ago
*** Bug 317762 has been marked as a duplicate of this bug. ***
Blocks: 187915

Comment 26

11 years ago
(In reply to comment #20)
> 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?

Comment 28

11 years ago
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)

Comment 31

11 years ago
(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.

Comment 32

10 years ago
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?
Assignee: law → nobody
QA Contact: chrispetersen → file-handling

Comment 33

4 years ago
Bug is still reproducible in Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16.
Component: File Handling → File Handling
Product: Core → Firefox
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.