surely, there's something fishy here...

I agree that $g_inline_file_exts and $g_preview_image_extensions should be reviewed and, if appropriate, consolidated.
At first glance, the $g_inline_file_exts should go away entirely, as I can't really see the value in seeing an image when I click on a "download" link.

However, I note that my poor english interpret:

Specifies the maximum size (in bytes) below which an attachment is

previewed in the bug view pages.

To disable this feature, set max size to 0.

as:
set it to 0 to disable the preview feature, not the limit feature, so probably we just need to clarify the remark.

Hmm, I read that as:

• The "feature" is selecting a maximum size for attachments that should be preview-able.
• Disabling the feature, to me, means disabling the maximum size, such that there is no size limit to what files can be previewed.

Surely if you didn't want any attachments to be shown inline or with a preview, you could either:

• Set both *_extension arrays to contain no items, or
• Set the maximum size to '1' such that any file will by necenssity be greater than 1 byte, thereby excluding all files

I personally think it makes much more sense to allow "some or no limit" than to only allow a choice of some arbitrary maximum size...

I think the inline file extensions and the preview images are two different things and they should probably remain separate. For example, an admin may disable preview for images but have them show inline when clicked. Or an admin may configure images + other files to show inline (e.g. text files / html).

However, I agree on the following:

1. The default for inline_file_exts should be revised to include all images.
2. We should have a consistent way to represent a list of extensions for all settings. We may even support both string / array, but we should be consistent.
3. The documentation of the configuration options should be enhanced to remove any possible confusion.

As for the preview disabling, we could do it through size or through setting the extensions to none. However, given we already had this option and it is working via the size, I see no reason to change it.

As for unlimited size for preview, we could use -1 for that. However, I think getting the admin to think about the max limit is not a bad thing. For example, do they want their users to preview images that are 1-5MB?

Retargetting the primary purpose of this issue for 1.2.x.

I think probably the "best" solution in my opinion is to:

• drop $g_inline_file_exts
• change file_download.php to use a combination of $g_preview_image_extensions and $g_preview_text_extensions in place of $g_inline_file_exts

To me, this makes more sense, and is less prone to getting out of sync when changing configs. I can't really think of any valid reason why you would want to show attachments inline when viewing the bug, or vice versa, and I think the added simplicity of removing the repetitive config options is a win.

Thoughts?