Open
Bug 102380
Opened 23 years ago
Updated 2 months ago
"Open in New Window" -> download or helper app leaves extra blank window
Categories
(Firefox :: File Handling, defect, P5)
Firefox
File Handling
Tracking
()
NEW
People
(Reporter: vectro, Unassigned)
References
(Blocks 2 open bugs)
Details
Attachments
(1 file, 1 obsolete file)
128 bytes,
video/foobar
|
Details |
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•23 years ago
|
||
Verified at http://www.google.com/search?hl=en&q=pdf+mozilla on Win98.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•23 years ago
|
||
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.
Updated•23 years ago
|
Blocks: link-modifiers
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•23 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]
Updated•23 years ago
|
Whiteboard: [Aufbau-P5]
Comment 6•23 years ago
|
||
Comment 7•23 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•23 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•23 years ago
|
||
Andrew, that makes no sense. *Everything* that can be downloaded, including HTML, has a MIME type.
Comment 10•23 years ago
|
||
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•22 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•22 years ago
|
||
*** Bug 136945 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
QA Contact: sairuh → petersen
Comment 13•22 years ago
|
||
*** Bug 173110 has been marked as a duplicate of this bug. ***
Comment 14•21 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•21 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•21 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•21 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 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•21 years ago
|
||
*** Bug 229318 has been marked as a duplicate of this bug. ***
Comment 19•21 years ago
|
||
*** 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.
Updated•20 years ago
|
Flags: blocking1.8a2?
Comment 21•20 years ago
|
||
*** Bug 246141 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Flags: blocking1.8a2? → blocking1.8a2-
Comment 22•20 years ago
|
||
now there is a bug for Firefox, see bug 251140
Comment 23•20 years ago
|
||
*** Bug 282345 has been marked as a duplicate of this bug. ***
Comment 24•19 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•19 years ago
|
||
*** Bug 317762 has been marked as a duplicate of this bug. ***
Blocks: 187915
Comment 26•18 years ago
|
||
(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•18 years ago
|
||
Is this something that should be fixed or should this be resolved wontfix?
Comment 28•18 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.
Comment 29•18 years ago
|
||
On the trunk anyway, I see blank windows on occasion still.
Comment 30•18 years ago
|
||
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•18 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•17 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?
Updated•16 years ago
|
Assignee: law → nobody
QA Contact: chrispetersen → file-handling
Comment 33•11 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.
Updated•8 years ago
|
Product: Core → Firefox
Version: Trunk → unspecified
Comment 35•6 years ago
|
||
Still reproducible with Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3.
Comment 36•6 years ago
|
||
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•6 years ago
|
||
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.
Flags: needinfo?(vectro)
Priority: -- → P5
Comment 38•6 years ago
|
||
(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
Updated•2 years ago
|
Severity: minor → S4
Comment 39•2 years ago
|
||
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.
Flags: needinfo?(gijskruitbosch+bugs)
Comment 40•2 years ago
|
||
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.
Flags: needinfo?(gijskruitbosch+bugs)
Comment hidden (spam) |
Updated•2 months ago
|
Attachment #9387209 -
Attachment is obsolete: true
You need to log in
before you can comment on or make changes to this bug.
Description
•