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

Status: NEW

(Firefox :: File Handling, defect, P5)

Description

[vectro]

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

[Jesse Ruderman]

Verified at http://www.google.com/search?hl=en&q=pdf+mozilla on Win98.

Comment 2

[Gervase Markham [:gerv]]

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

Comment 3

[vectro]

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.

Comment 4

[vectro]

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

[Niels Aufbau]

[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.

Comment 6

[Matthew T (active 1999-2002)]

Attachment: testcase

Comment 7

[Matthew T (active 1999-2002)]

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

[Andrew Hagen]

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

[Garth Wallace]

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

Comment 10

[Andrew Hagen]

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.

Comment 11

[Jesse Ruderman]

-> file handling

From dup bug 136945: this also happens with "open link in new tab".

Comment 12

[Jesse Ruderman]

*** Bug 136945 has been marked as a duplicate of this bug. ***

Comment 13

[Chris Lyon]

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

Comment 14

[Thomas Miller]

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

[Bertrand Legendre]

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

[Robert Wilson]

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

[Ben Basson]

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
happen.

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

[José Jeria]

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

Comment 19

[Alfonso Martinez]

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

Comment 20

[Bradley Chapman (not reading bugmail, still gone but not forever)]

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.

Comment 21

[Jesse Ruderman]

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

Comment 22

[OstGote!]

now there is a bug for Firefox, see bug 251140

Comment 23

[Alexander Martynovich]

*** Bug 282345 has been marked as a duplicate of this bug. ***

Comment 24

[Kris Silver]

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

[Jesse Ruderman]

*** Bug 317762 has been marked as a duplicate of this bug. ***

Comment 26

[Worcester12345]

(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. 

Comment 27

[Majken Connor [:Kensie]]

Is this something that should be fixed or should this be resolved wontfix?

Comment 28

[Ido Beeri]

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.

Comment 29

[Ryan VanderMeulen [:RyanVM]]

On the trunk anyway, I see blank windows on occasion still.

Comment 30

[Majken Connor [:Kensie]]

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

[Worcester12345]

(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

[Akkana Peck]

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?

Comment 33

[Tristan Miller]

Bug is still reproducible in Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16.

Comment 34

[Worcester12345]

Is this one "WORKS FOR ME" yet?

Comment 35

[Tristan Miller]

Still reproducible with Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3.

Comment 36

[Tristan Miller]

Oh, I just noticed that this bug was reassigned from Core to Firefox two years ago.  This seems rather strange, since the bug was originally filed against the Mozilla Application Suite (i.e., ur-SeaMonkey) and there was already a separate issue for Firefox (Bug 251140).  Maybe this bug should be assigned back to Core?  Or should I open a separate bug for SeaMonkey now?

Comment 37

[:Paolo Amadini]

File Handling is probably the right component if this is still an issue in Firefox. You may want a separate bug for SeaMonkey, or just change the component of this bug if this is not an issue in Firefox anymore.

Comment 38

[Tristan Miller]

(In reply to :Paolo Amadini [Away] from comment #37)
> File Handling is probably the right component if this is still an issue in
> Firefox. You may want a separate bug for SeaMonkey, or just change the
> component of this bug if this is not an issue in Firefox anymore.

I have opened a new bug for SeaMonkey: Bug 1475230

Comment 39

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S4. However, the bug has 7 duplicates and 53 votes.
:Gijs, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 40

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.