As per comment #0 we have tested this issue on reported chrome version 67.0.3396.62 and latest chrome stable 67.0.3396.87 using Linux 17.10. Attaching screen-cast for reference.
Steps:
--------
1. Launched chrome
2. Navigated to given URL ""https://www.w3schools.com/TAGS/tryit.asp?filename=tryhtml_input_accept""
3. Clicked on browse and selected image and clicked on submit > successfully submitted
4. Clicked on browse and navigated video folder > we have not seen video files to upload
We are able to load only image format files

@Reporter: As we are unable to reproduce the issue from our end. Can you verify this issue with fresh profile that is not having any extensions and apps or reset all the flags. Let us know whether issue still persists..

Thanks.!

Deleted: 855943.webm 6.6 MB

	855943.webm 6.6 MB View Download

Here is my screencast. As you can see - all files are visible.

Is it possible that openSUSE's build is somewhat specific in regards to this? I.e. - is there some compile configuration setting which may be affecting this and which openSUSE may have used? If that is the case - I can report to openSUSE's bugzilla. Please let me know.

Deleted: screencast.ogv 1.3 MB

	screencast.ogv 1.3 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

This may be a KDE-specific issue.
We have code to specify MIME filter, and it might have an issue.

https://cs.chromium.org/chromium/src/chrome/browser/ui/libgtkui/select_file_dialog_impl_kde.cc?type=cs&sq=package:chromium&g=0&l=366
https://techbase.kde.org/Development/Tutorials/Shell_Scripting_with_KDE_Dialogs#Example_31._--getopenfilename_dialog_box_with_MIME_filter

I cannot open the first link because the site requires javascript and I am not willing to enable it.

Testing with the command from the second link (Example 31) works just like shown on the screenshot.

Reporter@ Thanks for the update.

As per comment #4 and #6, this is KDE-specific issue and this setup is not available at TE end to triage further.
Hence adding 'TE-NeedsTriageFromHYD' and requesting Inhouse team to look into this issue and help further.

Thanks..

Tested this issue on Debian Rodete with chrome #67.0.3396.62 and stable #67.0.3396.99

Observations:
=============
1. On Clicking on Choose file, by default image files are selected and only displayed image files.
2. If we change the option to All files, it displaying all file types.
3. If we select any non image file and click on submit, it is displaying "pic = non image file name"

Attaching the screen-cast for reference.

studio@ Could you please confirm this is the issue, you are facing ?

Deleted: 855943.mp4 1.6 MB

	855943.mp4 1.6 MB View Download

> studio@ Could you please confirm this is the issue, you are facing ?

No. As seen on my video regardless of the accept="image/*" the filter dropdown shows "All Supported Files" (including non-images).

Thank you for providing more feedback. Adding the requester to the cc list.

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

Able to reproduce this issue on Debian Rodete, Windows and Mac 10.13.4 with stable #67.0.3396.99, Canary #69.0.3488.0 and also on earlier version M60-#60.0.3072.0
This is a non-regression issue, hence marking it as untriaged.

Requesting the dev team to look into this issue.

Attaching the screen-cast for reference.

Deleted: 855943-M60.mp4 741 KB

	855943-M60.mp4 741 KB View Download

The summary is misleading; the accept attribute restricts the initial filter presented in the file picker. What it doesn't do is prevent the user from changing the filter. This applies to all of Linux/Mac/Win.

Safari: filters to image files, no option to show all file types
Firefox: filters to image files, but user can change option (mac/win/linux)
Chrome: filters to image files, but user can change option (mac/win/linux)
Edge: doesn't filter at all

It sounds like the reporter is interested in matching Safari behavior, but that seems somewhat user-hostile.