@415658599: Could you please provide us the sameple .html file to repro this issue from our end, which would help us in triaging it further.

Thank you.

415658599@, what platform are you using?

Here is the example that contains these 2 conditions.

1. If a html has a input which type is file, and has attribute accept & multiple,
then when I click the browse，The system's file-select-popup appears a little slow. The main code just below:
<input type="file" accept="image/*" multiple="multiple">

2. If a html has a input which type is file, and doesn't have attribute accept or multiple, then when I click the browse，The system's file-select-popup appears very quickly. The main code just below:
<input type="file">

Deleted: example.html 401 bytes

example.html 401 bytes View Download

Windows and Mac are all used to test this example.

With example.html in #4, I observed any speed difference between two file inputs.

Do you have many files in the default directory shown in the file chooser dialog?

same problem, when I click <input type="file" accept="image/*"> , chrome slow(1.5s ~2s) response files dialog.

OS: MacOS EI Capitan 10.11.6
ChromeVersion: 53.0.2785.101 (64-bit)
without chrome extensions & use safebrowsing same bug.

pls chromium improve this feature.

Thank you for providing more feedback. Adding requester "rnimmagadda@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

 Issue 648541  has been merged into this issue.

 Issue 648877  has been merged into this issue.

Everyone,
Does Disabling or enabling chrome://flags/#enable-site-per-process affect the behavior?

No, changing the enable-site-per-process flag has no effect.

You can try this page:
http://60.205.145.196/download/test.html

It seems like this issue is specific to cases where the newer wildcard format for the accept attribute (e.g. "image/*", "video/*") is used.

As a temporary workaround, it's possible to replace:

<input type="file" name="images[]" multiple="multiple" accept="image/*">

with:

<input type="file" name="images[]" multiple="multiple" accept="image/gif, image/png, image/jpeg, image/bmp, image/webp">

Able to repro this issue on Windows 7, MAC (10.11.6) & Ubuntu Trusty (14.04) for Google Chrome Stable Version - 53.0.2785.143 & Canary Version - 55.0.2875.0

This is a Non-Regression issue existing from M30 - # 30.0.1549.0

Deleted: 638874.mov 10.7 MB

638874.mov 10.7 MB Download

I don't think this bug exists since M30.  We received multiple reports since M52 or M53.

nasko@, do you have any insights on this?

I've mostly moved code around for file selection, don't really know much about it.

 Issue 669399  has been merged into this issue.

 Issue 672406  has been merged into this issue.

 Issue 678507  has been merged into this issue.

doubt caused by `image/svg` or `image/svg+xml`

Chrome 60 is still with this issue. :( 

As the specific system environment, the bug ( Issue 638874 ) still reveals in Chrome v55(mac x64, release channel), Chrome v58(windows x64, release channel).

I think this issue is related to  'safebrowsing' feature

When using fiddler to capture http requests,  each time upload button is clicked,  chrome sends the following request :

-------------------------------
      POST https://sb-ssl.google.com/safebrowsing/clientreport/download?key=xxxxxxxxxxxxxxxx HTTP/1.1
      Host: sb-ssl.google.com
      Connection: keep-alive
      Content-Length: 194
      Content-Type: application/octet-stream
      User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
      Accept-Encoding: gzip, deflate, br
      Cookie: XXXXXXXXXXXXXX


      Mhttps://www.kesci.com/apps/home/XXXXXXXXXX  "Q
      Mhttps://www.kesci.com/apps/home/XXXXXXXXXXJ.zipP   

 .zip   


-------------------------------


When your network condition is not good or you are using chrome in China ( where google servers are blocked) , this request takes a few seconds to fail,  and this may cause the dialog pops up slowly 


Please fix this

This issue is barely noticeable on my laptop with decent internet speed.  But at our lab, access to the internet blocked with a small list of exceptions, usually read-only.  In this case, it's extremely pronounced, sometimes greatly exceeding 6 seconds.  For our application, this leaves the user clicking the browse button many times, and the dialog opening as many times as the button was clicked... but the subsequent dialogs open after the preceding one is closed.  Not blocking, but misleading and frustrating.  This means our customers that deploy products in labs with similar restrictions will see this same behavior using Chrome.

My version is 52.0.2743.82 m (64-bit)
A coworker of mine didn't see this behavior, same lab, but using version 49.0.2623.110

Our particular usage was using a comma-separated list of specific file types, so I've create an example which added a few different scenarios, riffing off the HTML file attached earlier.

Deleted: index.html 815 bytes

index.html 815 bytes View Download

Add SafeBrowsing components according to #25.

https://chromium-review.googlesource.com/c/514582/

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

commit 2ea5bc1b20559b052319bc81f1956f0e018b6548
Author: Asanka Herath <asanka@chromium.org>
Date: Tue May 30 14:42:14 2017

Only perform SafeBrowsing checks for file choosers that save files.

SafeBrowsing checks only make sense when saving. Skip the check on
uploads.

FileSelectHelper makes numerous thread hops while preparing a file
chooser on behalf of a renderer. It is possible for the renderer to be
destroyed during this time. FileSelectHelper should check whether the
renderer is still alive each time it returns to the UI thread and abort
the operation if the renderer has gone away.

Bug: 680080
Bug:  638874 
Change-Id: Iaf5f72fc5c7504259813f5ab2f607aef755e365d
Reviewed-on: https://chromium-review.googlesource.com/514582
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Asanka Herath <asanka@chromium.org>
Cr-Commit-Position: refs/heads/master@{#475522}
[modify] https://crrev.com/2ea5bc1b20559b052319bc81f1956f0e018b6548/PRESUBMIT.py
[modify] https://crrev.com/2ea5bc1b20559b052319bc81f1956f0e018b6548/chrome/browser/file_select_helper.cc
[modify] https://crrev.com/2ea5bc1b20559b052319bc81f1956f0e018b6548/chrome/browser/file_select_helper.h
[modify] https://crrev.com/2ea5bc1b20559b052319bc81f1956f0e018b6548/chrome/test/ppapi/ppapi_filechooser_browsertest.cc

Needs someone to verify after this lands in Canary.

 Issue 739068  has been merged into this issue.

I can confirm this is fixed for me in

$ google-chrome-unstable --version
Google Chrome 61.0.3159.5 dev

Thanks so much, Asanka, this makes uploading multiple files (which I do all the time) amazingly better!