input['file'] accept=“image/*” open dialog so slow with Chrome

后端 未结 3 2053
旧巷少年郎
旧巷少年郎 2021-02-14 07:32

When I use with Chrome, it opens the dialog very slowly (more than 10s on Mac 10.11.6 with Chrome 52.0.2743.116 64-b

相关标签:
3条回答
  • 2021-02-14 08:06

    I Think I may have found the reason, at least on my machine:

    When my internet connection is on, it opens fast the file dialog, when I turn it off, it is slow, then I turn it on again and it is fast again.

    Therefore try opening the file dialog when your internet connection is on, and see if there is any difference. It worked for me.

    0 讨论(0)
  • 2021-02-14 08:22

    UPDATE in Jul. 2017: This is confirmed as a bug in Chrome, and it is fixed now.

    The root cause of this bug is: Chrome's SafeBrowsing feature will check file on uploading or saving. If the internet connection to google's server is fast, it's OK. But if the connection is slow or broken, SafeBrowsing will make Chrome hang for a few seconds, until the check is finished or timeout.

    Using accept="image/png, image/jpeg, image/gif" will workaround this issue because MIME types image/png, image/jpeg, image/gif are in the whitelist of SafeBrowsing -- no check is needed. However, for accept="image/*" or accept=".apk", as it's not in the whitelist, SafeBrowsing will trigger the check and hang Chrome.

    This bug has been fixed by skip the check on uploading.

    Note: I get the above information from a Chinese article written by Wang Lei, who is inspired by @cute_ptr's answer. Thanks to Wang Lei and I think @cute_ptr's answer deserve an upvote.


    UPDATE: Thanks to @xiefei's comment, the final workaround would be: <input type="file" name="imgFile" accept="image/png, image/jpeg, image/gif">. If necessary, other image MIME types can be appended.


    This bug is reproduced on my machine: Mac + Chrome + <input type="file" accept="image/*">. It seems like a Chrome bug on Mac when accept attribute is used, as it's not reproduced on Windows environment, or on other browsers.

    0 讨论(0)
  • 2021-02-14 08:30

    From the best answer, we have known this is a chrome bug and ready to be fixed. Until today(2017/08/23), chrome 60.0.3112.101 has not fixed this bug yet. However latest chrome canary(62.0.3194.0) has fixed it.

    0 讨论(0)
提交回复
热议问题