Bugzilla apparently wrongly interprets attachment mimetypes in some cases. SHARs and unidiff patches are sometimes interpreted as application/octet-stream (eg. bug #205485 where I fixed it to proper PATCH type). The result of that is increased difficulty in reviewing the attachments that then require download and colorized diff view elsewhee.
I'll try various attachments against this bug to see how bugzilla interprets them.
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 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]
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.
Fixed in bug #213923