This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I don't believe this was always the case in Issuezilla, but it is now. See the attachment link given in the URL field (from issue #29383). It is a GIF image. When I click on this link in Mozilla 1.2.1/Linux, I am asked to save a file of type image/gif to disk. But all I wanted was to look at it in the browser, not download and save it. The same happens for other MIME types that the browser is quite capable of viewing directly - text/plain, etc. Examining HTTP headers with netcat, I see that the guilty headers are: Content-disposition: attachment; filename=NBSplash_3_4_1.gif Content-Type: image/gif; name=NBSplash_3_4_1.gif Why the "Content-disposition: attachment" line? If you just delete that header line, the browser displays the image like you would expect. For MIME types that you probably want to save - application/*, for example - the content-disposition header makes sense, since it permits a filename to be specified. Suggest either: 1. Selected common inline-viewable types, e.g. image/* and text/*, be given content-disposition: inline. 2. The IZ page for an issue have two links for each existing attachment: one to save as an attachment (giving the filename), one to view directly in the browser (assuming the browser can render that MIME type).
Jesse, your issue is an oposite to solution for issue 8883. IMHO according to RFC 2616 your issue belongs to mozilla.org ;-( http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.5.1 See related mozilla.org bugs: http://bugzilla.mozilla.org/show_bug.cgi?id=98360 http://bugzilla.mozilla.org/show_bug.cgi?id=62760 From my point of view your issue is browser-related and though invalid ;-(.
Thanks for the tip (I missed Moz #98360 before since it was marked FIXED), I filed: http://bugzilla.mozilla.org/show_bug.cgi?id=185618
As mentioned by Boris here: http://bugzilla.mozilla.org/show_bug.cgi?id=185618#c2 IZ can in fact do better. Just use 'inline' rather than 'attachment' as the disposition, but continue to supply a filename. At least in Moz 1.2.1, if the browser can display it inline, it will, but Ctrl-S will use the supplied filename as a default; if it cannot be displayed inline, a save dialog will be shown, again with the correct default filename. Someone using IE can confirm that the proposed change would at least be no worse for IE users. See http://www.ietf.org/rfc/rfc1806.txt ss. 2.3: "The presence of the filename parameter does not force an implementation to write the entity to a separate file. It is perfectly acceptable for implementations to leave the entity as part of the normal mail stream unless the user requests otherwise. As a consequence, the parameter may be used on any MIME entity, even 'inline' ones. These will not normally be written to files, but the parameter could be used to provide a filename if the receiving user should choose to write the part to a file."
Hi Jesse, I think you remember correctly meaning that the described behavior is somewhat new. It does not occur when I use Mozilla 1.0.1/linux. It does however with Mozilla 1.2 and higher including 1.3a. I'd file internal issue for management to evaluate request.
update: filed internal issue pcn 14314 for management. action plan: monitor internal issue for updates next update: upon reply from management.
Gili this problem in Issuezilla is the root of the problem; recent versions of Mozilla are behaving as the server requested. Of more interest: this bug was already fixed in Bugzilla! See attachment.cgi: revision 1.25 date: 2002/09/28 04:10:27; author: justdave%syndicomm.com; state: Exp; lines: +1 -7 Fix for bug 171296: changing Content-disposition header in attachment.cgi to use 'inline' instead of 'attachment' so that it doesn't *force* you to download it. r= bbaetz, bzbarsky More info: http://bugzilla.mozilla.org/show_bug.cgi?id=171296
Note that the behavior is even more annoying under Mozilla 1.3 due to changes in the attachment handler dialog. Any update on status of this fix? The patch is probably trivial; the Bugzilla patch was done months ago and only affected a few lines of code (making them simpler)! http://bugzilla.mozilla.org/attachment.cgi?id=100971&action=view
I have asked for an engineering update to this issue. I will update the issue by 4/11 & escalate by 4/14 if I do not get a response. Eric
This issue can be checked again with the recent releases of Mozilla and also in 2.6 stage. So currently closing this as fixed, NB can reopen this again if it reoccurs in 2.6 too. Priya.
This is still a problem with Mozilla 1.4, the latest release from mozilla.org. Is the Issuezilla bug actually patched and fixed in SourceCast 2.6 (I am assuming that is what "2.6" refers to), or are you just saying we should try SC 2.6 when available and see if someone happened to fix it by accident? I don't really understand this resolution. Has any engineer actually confirmed that the problem is fixed (when using e.g. Moz 1.4) with a development version of SC's Issuezilla?
I have tested this in the stage of NB(I mean the 2.6 here) (Mozilla /linux)to verify this, it worked fine. And also this has been tested early with the stable realese of mozilla 1.0.2, it worked. Sorry that i should have asked you to verify this. This is not occuring in 2.6 too.(Stage of NB). So how do we go now on this? Priya.
Sripriya, the original report was for Moz 1.2.1; later Jesse adds that the problem still exists in 1.3, and 1.4. You comment that it is fixed in SC2.6 for Moz 1.0.2 - but what about for the reported versions of Mox ? Until we know it is fixed for the versions of Moz this issue was reported against (1.2 and later), it is still an open issue IMO.
Hi Jack! I have tested this with 1.2 and later(1.3,1.4) in stage box (2.6) of Netbeans, i can able to open the atachments directly. I dont get any dialog box which is asking for save. Thanks, Priya
Closing this as resolved fixed for now and will review this issue in the forthcoming 2.6 release and will reopen or close as necessary. Thanks, Priya
*** Issue 42289 has been marked as a duplicate of this issue. ***
Verified that the issue has been fixed. Regards, Karishma Support Operations
We recently moved out from Collabnet's infrastructure