Confirmed. I see the same behaviour, and second Rainer’s request: Please switch back to “Auto-detect”! That worked better as default value, especially for the averange bug reporter who is just a normal user whithout (as it seems) much knowledge about file formats.

Thank you very much!

The 'autodetect' relies on content type sent by browser.

Mozilla based browsers send file type based on file extension only.

Specifically, they send files with .log extension as application/octet-stream or text/x-log neither of which they are willing to open when sent by the server.

The Mozilla foundantion browsers and bug tracking system are really well made to fit together.

Looks like the official fix is scheduled for bugzilla 4.4

https://bugzilla.mozilla.org/show_bug.cgi?id=622455

Created attachment 67726 [details]
image attachment test

Created attachment 67727 [details]
log file test

I think there might be a little confusion here. There was a previous request to have the attachment type default to text/plain as in bug 53957. 

There is an additional issue that when choosing auto-detect that bugzilla doesn't always do the right thing.. but this is because the browser sends bad information. This issue will officially fix in bugzilla 4.4. Until then I've installed the typesniffer bugzilla extension that queries the mime type via magic queries. 

Sadly using firefox, .log files still don't work :(

Hence until a work around can be found that makes .log files remain as text, the text/plain default stays.

Sorry, my mistake, I wrote this report rather sloppy, and so it was mistakable and seemed to be related to <https://bugzilla.mozilla.org/show_bug.cgi?id=622455>. 

Here in this report we are talking about the radio buttons on the "Create New Attachment" page, what in the past were by default on "auto-detect", but now they are on "select from list" (with preselection "text/plain").

Please switch default back to "auto-detect".

We have no problems with fix for bug 53957, what seems to make "text/plain" as default for method  "select from list".


@Benjamin Close:
Please excuse me for the carelessness

The bit that is missing here is that this bug and bug 53957 are related. As the fix for bug 53957 was changing the radio button default to the list:


commit 0e6f60f2ddec54f4fb86255ff913e1217489216c
Author: Tollef Fog Heen <tfheen@err.no>
Date:   Wed Sep 19 20:35:03 2012 +0200

    Set content type detection to list (defaulting to text/plain)

diff --git a/template/en/default/attachment/createformcontents.html.tmpl b/template/en/default/attachment/createformcontents.html.tmpl
index d0ca336..e17c07e 100644
--- a/template/en/default/attachment/createformcontents.html.tmpl
+++ b/template/en/default/attachment/createformcontents.html.tmpl
@@ -79,10 +79,10 @@
 
     <em>Otherwise, choose a method for determining the content type.</em><br>
     <input type="radio" id="autodetect"
-           name="contenttypemethod" value="autodetect" checked="checked">
+           name="contenttypemethod" value="autodetect">
       <label for="autodetect">auto-detect</label><br>
     <input type="radio" id="list"
-           name="contenttypemethod" value="list">
+           name="contenttypemethod" value="list" checked="checked">
       <label for="list">select from list</label>:
       <select name="contenttypeselection" id="contenttypeselection"
               onchange="this.form.contenttypemethod[1].checked = true;">


Hence to fix this bug reverts bug 53957. Whilst initially I was against that I have a feeling that another bug - bug 55357 is occurring as a side affect of the above change as well. I'm out of time to work on this further now. The real fix is work out why the type sniffer plugin didn't change the tested log file mime type correctly. If that can be fixed then we can revert back to auto and everyone is happy.

]] 

> Hence to fix this bug reverts bug 53957. Whilst initially I was against that I
> have a feeling that another bug - bug 55357 is occurring as a side affect of
> the above change as well. I'm out of time to work on this further now. The real
> fix is work out why the type sniffer plugin didn't change the tested log file
> mime type correctly. If that can be fixed then we can revert back to auto and
> everyone is happy.

There is no type sniffer plugin.  It looks at what the user's browser
selects, and it quite often just selects application/octet-stream.

There are a few options:

- Rewrite application/octet-stream to text/plain (somewhat icky)
- Make the default vary depending on product, so libreoffice can have
  auto while other projects have select-from-list
- Fix the underlying bug (as planned for 4.4).

I'm tempted to just go with option 2 for now, until the new bugzilla
version is released.

Created attachment 67768 [details]
log file test 2

Testing with modified type sniffer plugin.. we want this to auto detect as text/plain

Created attachment 67769 [details]
log file test 3

Making sure chef doesn't remove the required lib file-mimeinfo-perl package might make this work..

Created attachment 67770 [details]
log file test 3

Testing to see if the type sniffer plugin is actually working (exit in plugin)

Created attachment 67771 [details]
another test

*** Bug 55506 has been marked as a duplicate of this bug. ***

Hi guys, thanks a lot for working on it. I am looking forward to see this fixed. The current situation is a pain because 99% of attachments for LibreOffice bugs have wrong MIME. In addition, the "text/plain" MIME causes that all binary content is displayed in browser as a mess. Yes, you still could save it but...

I understand that some other projects have many log files. Well, the browser allows to save such files or display using another application. This is IMHO less painful than being confused by a mess from binary files :-)

Hi!
I totally agree tp Petr... It is a pain to see user, trying to upload pictures six or more time, because it looks like mess... Please change that ASAP...

(In reply to comment #15)
> The current situation is a pain because 99% of attachments for
> LibreOffice bugs have wrong MIME. In addition, the "text/plain" MIME causes
> that all binary content is displayed in browser as a mess. 

This is still valid for LibreOffice project, where reporters are uploading numerous different file types as attachments. As https://bugs.freedesktop.org/attachment.cgi?id=67771&action=edit links do not provide select in the MIME Type: field correcting this is a PITA and waste of time for QA people.
Please consider introducing:

(In reply to comment #9)
>> - Make the default vary depending on product, so libreoffice can have
>>   auto while other projects have select-from-list
> I'm tempted to just go with option 2 for now, until the new bugzilla
> version is released.

as 

(In reply to comment #3)
> Looks like the official fix is scheduled for bugzilla 4.4
> https://bugzilla.mozilla.org/show_bug.cgi?id=622455

won't be included in 4.4.

Other option is to finish testing of http://bzr.mozilla.org/bmo/4.2/files/head:/extensions/TypeSniffer/ extension as mentioned in comment 6, comment 10 and comment 11.

This should be fixed now, it's now autodetect again for LO.

(In reply to comment #18)
> This should be fixed now, it's now autodetect again for LO.

Thank you Tollef _o_ _o_ ! You saved a lot of time for us!