Bug 205623
| Summary: | Some attachments, in some cases, are not easily viewable in the browser | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Services | Reporter: | VK <vlad-fbsd> | ||||||||||||||||||||
| Component: | Bug Tracker | Assignee: | Bugmeister <bugmeister> | ||||||||||||||||||||
| Status: | Closed FIXED | ||||||||||||||||||||||
| Severity: | Affects Some People | CC: | bugmeister, clusteradm, gonzo | ||||||||||||||||||||
| Priority: | --- | Keywords: | feature, needs-qa | ||||||||||||||||||||
| Version: | unspecified | ||||||||||||||||||||||
| Hardware: | Any | ||||||||||||||||||||||
| OS: | Any | ||||||||||||||||||||||
| See Also: |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213332 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213923 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226337 |
||||||||||||||||||||||
| Bug Depends on: | 213923 | ||||||||||||||||||||||
| Bug Blocks: | |||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||
|
Description
VK
2015-12-26 11:25:33 UTC
Created attachment 164671 [details]
A svn diff patch with extension
A SVN diff patch with extension, PATCH checkbox NOT checked, content-type determination method AUTO-DETECT
Created attachment 164672 [details]
A svn diff patch without extension
A SVN diff patch WITHOUT extension, PATCH checkbox NOT checked, content-type determination method AUTO-DETECT
The example bug in the original post here is wrong, I apologize. This is the correct bug: bug #205284. The patches were shown as application/octet-stream and I had to manually check the PATCH checkbox on them to show as patches with diff view. Created attachment 164674 [details] The new file files/extra-patch-sidebar-refresh This the file I downloaded directly from bug #205284 (attachment: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=164587) when I clicked the patch to view it, BEFORE I changed that attachment to be a PATCH (checkbox'd). Here I do NOT check the PATCH checkbox and using default auto-detect content type determination. Created attachment 164675 [details] poudriere build log for devel/apache-archiva Attaching poudriere log from bug #203071 (attachment https://bugs.freebsd.org/bugzilla/attachment.cgi?id=164627) that is set as text/x-log. This triggers download on Firefox 43, Ubuntu 15.10. Here uploaded as auto-detect, filename not changed, description copied from the bug. Created attachment 164676 [details] shar archive SHAR file from bug #205311 (attachment https://bugs.freebsd.org/bugzilla/attachment.cgi?id=164227). The attachment is re-uploaded here for test. Has .shar extension, will probably result with the same application/shar mimetype (with auto-detect content type). Created attachment 164677 [details]
shar archive
Same etcd SHAR as above, but without extension in the filename. Let's see what happens to it.
Content type auto-detect.
My summary of the issue so far is this. 1. I believe the patches from bug #205284 were manually selected to be "binary file" which resulted with application/octet-stream mimetype, unless there's an internal problem not visible to me in this test. Because the same files re-attached here with auto-detect, were detected correctly even without the PATCH checkbox checked. 2. The x-log thing is probably correct behaviour because of .log extension on the attachment, but I propose those be set as text/plain and in case the file size is larger than a few MB, force content-disposition: attachment in the response header, leaving mimetype text/plain. 3. The .shar extension resulted with application/x-shar mimetype. I don't know if that is expected, but I believe it should be set to a mimetype like text/plain. Perhaps the same content-disposition rule as above. Re-uploading the file without the .shar attachment set it to text/plain mimetype. Further, I propose this: 1) attachment content-type selection be omitted from the upload page and left to auto-detection. 2) all auto-detected mimetypes be left original, IF that is of importance or for purpose of correctness. Eg. shar application/(x-)shar for shar files, application/x-log for logs (although logs ARE plain text). BUT THEN have a "View in browser" link in the third column (with Details | Diff) that will force a viewable type (where applicable of course). You propose it, you own it :) Created attachment 175557 [details]
Copy pasted multiline text
Testing multiline paste
Created attachment 175558 [details]
test patch copy & paste
Created attachment 175559 [details]
patch as normal text (not marked as patch)
(In reply to Kubilay Kocak from comment #10) > > You propose it, you own it :) What I *think* should be done with this now is the following: 1. Clusteradm (CC) or whoever is responsible for the Bugzilla configuration should take a look at the problem and see if it's something that can be easily configured for, or requires code modification. 2. Base whatever further action is required on results of #1. As I have no access to config, code, servers, or any authority to even begin looking into this (and I don't know why you thought I do, koobs :) ), I'm returning this to Bugmeister for further consideration. Oops. Fixed in bug #213923 |
