open file dialog pointed to slow network drive share on windoows blocks tab switching and hangs
Reported by
paulfris...@gmail.com,
Sep 20
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 Steps to reproduce the problem: 1. Mount a very slow network drive. A mountainduck mapped Google Drive when accessing the (virtual) "Google Photos" folder in your drive will do. 2. Navigate to a page where you can upload a file. 3. Navigate to a huge folder on your network drive. Everything will start to hang and you cannot even go and save your work on other chrome tabs in the same window. What is the expected behavior? You should be able to switch to another tab in the same window while the "open file" dialog is enumerating the network drive for a different tab. You should eventually be able to select a file. What went wrong? You cannot switch to another tab on the same chrome window. You have to kill chrome if you want to resume working with it (if you only had one window open) if the network drive stays unresponsive. Did this work before? N/A Chrome version: 69.0.3497.100 Channel: stable OS Version: 10.0 Flash Version: I don't care that this API is synchronous in windows. Start another process and communicate with it if you have to to fix this. There could be a timeout for selecting a file
,
Sep 20
,
Oct 5
Thanks for filing the issue! The issue seems to be out of scope for us to triage it further without having/mounting a very slow network drive, hence adding component "Internals>Network" and requesting someone from respective team to have a look into this and help in further triaging it.
,
Oct 18
Removing from Internals>Network since all network shares are handled by the OS, rather than Chrome's network stack. This would need to be a blink/UI change.
,
Oct 19
It's difficult to open a modal dialog in a separated process, and its benefit would be low.
,
Oct 19
I accept the wontfix, but I don't agree with the difficult part. To me this looks like two processes exchanging a single string via stdio for example. Input is file extension spec, output is filename/abort/crash. Opening the modal file open dialog is trivial in any windows process. For reasons of ui consistency, you may still want to block the Javascript thread of the tab that created the dialog, but leave the rest be instead of crashing the whole process. Just because windows makes this a modal dialog does not mean it has to be used that way. When windows gives you lemons, make lemon juice :D Also, from what I see, the dialog is modal only wrt to one thread, so maybe it is just run in the wrong thread where it blocks too much of the tab switching logic. I remember when alerts made it impossible to switch and close tabs. Luckily that's over. tk… via monorail <monorail+v2.567034358@chromium.org> schrieb am Fr., 19. Okt. 2018, 02:38: |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by paulfris...@gmail.com
, Sep 20