Bug 205623 - Some attachments, in some cases, are not easily viewable in the browser
Summary: Some attachments, in some cases, are not easily viewable in the browser
Status: Closed FIXED
Alias: None
Product: Services
Classification: Unclassified
Component: Bug Tracker (show other bugs)
Version: unspecified
Hardware: Any Any
: --- Affects Some People
Assignee: Bugmeister
Keywords: feature, needs-qa
Depends on: 213923
  Show dependency treegraph
Reported: 2015-12-26 11:25 UTC by VK
Modified: 2018-03-04 11:31 UTC (History)
3 users (show)

See Also:

A svn diff patch with extension (977 bytes, patch)
2015-12-26 11:27 UTC, VK
no flags Details | Diff
A svn diff patch without extension (977 bytes, patch)
2015-12-26 11:30 UTC, VK
no flags Details | Diff
The new file files/extra-patch-sidebar-refresh (3.13 KB, patch)
2015-12-26 11:39 UTC, VK
no flags Details | Diff
poudriere build log for devel/apache-archiva (22.77 KB, text/x-log)
2015-12-26 11:49 UTC, VK
no flags Details
shar archive (3.13 KB, application/x-shar)
2015-12-26 12:03 UTC, VK
no flags Details
shar archive (3.13 KB, text/plain)
2015-12-26 12:12 UTC, VK
no flags Details
Copy pasted multiline text (68 bytes, text/plain)
2016-10-09 08:36 UTC, VK
no flags Details
test patch copy & paste (781 bytes, patch)
2016-10-09 08:39 UTC, VK
no flags Details | Diff
patch as normal text (not marked as patch) (781 bytes, text/plain)
2016-10-09 08:41 UTC, VK
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description VK freebsd_triage 2015-12-26 11:25:33 UTC
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.
Comment 1 VK freebsd_triage 2015-12-26 11:27:29 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
Comment 2 VK freebsd_triage 2015-12-26 11:30:59 UTC
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
Comment 3 VK freebsd_triage 2015-12-26 11:35:48 UTC
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.
Comment 4 VK freebsd_triage 2015-12-26 11:39:34 UTC
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.
Comment 5 VK freebsd_triage 2015-12-26 11:49:00 UTC
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.
Comment 6 VK freebsd_triage 2015-12-26 12:03:18 UTC
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).
Comment 7 VK freebsd_triage 2015-12-26 12:12:23 UTC
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.
Comment 8 VK freebsd_triage 2015-12-26 12:13:27 UTC
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.
Comment 9 VK freebsd_triage 2015-12-26 12:35:15 UTC
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).
Comment 10 Kubilay Kocak freebsd_committer freebsd_triage 2015-12-26 12:42:44 UTC
You propose it, you own it :)
Comment 11 VK freebsd_triage 2016-10-09 08:36:21 UTC
Created attachment 175557 [details]
Copy pasted multiline text

Testing multiline paste
Comment 12 VK freebsd_triage 2016-10-09 08:39:01 UTC
Created attachment 175558 [details]
test patch copy & paste
Comment 13 VK freebsd_triage 2016-10-09 08:41:29 UTC
Created attachment 175559 [details]
patch as normal text (not marked as patch)
Comment 14 VK freebsd_triage 2016-11-30 09:09:41 UTC
(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.
Comment 15 Jan Beich freebsd_committer 2017-04-23 18:11:49 UTC
Comment 16 Oleksandr Tymoshenko freebsd_committer freebsd_triage 2018-02-11 21:57:18 UTC
Fixed in bug #213923