Is this just happening on a particular site, or are downloads on all websites defaulting to .bin?

It is every site to the best of my knowledge. I've noticed it doesn't happen when I try to save the page, but if I try to save an image by right-clicking on Imgur or download an Ubuntu ISO from Ubuntu's website, for example, it will default to .bin. Unchecking the option to pick the file extension for me has prevented the problem for now.

This is most likely an issue with kdialog. Can you provide a screenshot of what you are seeing?

Here is a screenshot. The checkbox for auto-selecting the file extension should either have .iso selected or greyed out entirely. Firefox w/ kmozillahelper and Libreoffice, in my testing, do not have this problem.

Deleted: Screenshot_20170810_164451.png 74.3 KB

	Screenshot_20170810_164451.png 74.3 KB View Download

Thank you for providing more feedback. Adding requester "dahlke@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@dahlke -- A friendly ping. Could you please look into the issue.

Thanks!

 Issue 783149  has been merged into this issue.

 Issue 778513  has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c97cb6fa570ca93fe93a34a85ff88be5c51e8b92

commit c97cb6fa570ca93fe93a34a85ff88be5c51e8b92
Author: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Date: Mon Jan 29 19:57:07 2018

libgtkui: Use application/octet-stream as the last option in the KDE code

We were previously using an std::set<std::string> to filter out mime type
duplicates, optionally adding the "application/octet-stream" mime type to
the set before joining all items as a single string to pass to the
kdialog invocation.

This used to work fine with the KDE4-based kdialog, whose underlying
KFileDialog ended up creating a custom file type filter with all entries and
suggesting the proper file extension. The KDE Frameworks 5-based kdialog
that was released a few months ago uses a simple QFileDialog, and the
filter's entries are added in the order they are passed to kdialog.

In practice, this means that downloading a PDF file (or any file whose mime
type ended up coming after "application/octet-stream" when iterating our
std::set) causes kdialog to be invoked like this:

    kdialog [...] --getsavefilename /path/to/Downloads/foo.pdf \
                  application/octet-stream application/pdf

KDE4 kdialog suggests "foo.pdf" as the name and adds "unknown, PDF
document", "unknown" and "PDF document" to the filter list. KF5 kdialog
suggests "foo.bin" as the name and adds "unknown" and "PDF document" to the
filter list.

We now make sure that "application/octet-stream" is the last mime type we
pass to kdialog so that any other more specific mime type is chosen as the
default and we do not always try to add the ".bin" extension to the files we
are saving.

Bug:  752375 
Change-Id: I56a458042823c52beada9c1819c2ee4b8b8e5e30
Reviewed-on: https://chromium-review.googlesource.com/891160
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Reviewed-by: Elliot Glaysher <erg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#532556}
[modify] https://crrev.com/c97cb6fa570ca93fe93a34a85ff88be5c51e8b92/chrome/browser/ui/libgtkui/select_file_dialog_impl_kde.cc

The issue can't be verified from ET team due to the lack of KDE plasma set up. Hence, forwarding it to inhouse team for verification of the issue on opensuse as per the screenshot in comment #4.

Thanks...!!

 Issue 810344  has been merged into this issue.

 Issue 771601  has been merged into this issue.

Issue is fixed as of now. Only one thing. Filter should be default to whatever extension the the file is download to. If I download jpeg, it default should be to jpeg instead of unknown. Check the attachment above.

Deleted: Screenshot_20180216_015113.png 89.2 KB

	Screenshot_20180216_015113.png 89.2 KB View Download

Can you file a separate bug about that (and CC me there), preferably with an easy way to reproduce the issue?

https://bugs.chromium.org/p/chromium/issues/detail?id=816404#c4
I reported a separate bug.

 Issue 816404  has been merged into this issue.