New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 73 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 2
Type: Bug

Restricted
  • Only users with EditIssue permission may comment.


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment
link

Issue 103737: Very long wait for save file dialog to open when downloading a file (any file) the first time after starting chrome

Reported by marco.ki...@gmail.com, Nov 10 2011

Issue description

Chrome Version       : 15.0.874.106
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5:
Firefox 4.x:
IE 7/8/9:

What steps will reproduce the problem?
1. Close all Chrome browser windows
2. Open a new browser window
3. Navigate to any page where you can download a pdf/word/csv or any other downloadable file
4. Klick to download or rightclick and choose save target as.

What is the expected result?

A save file dialog should open immediatly.

What happens instead?

It takes a very long time (20 - 60 seconds) before the save file dialog opens. If you click several times (because nothing happens) you get several save dialog windows opening right after the fist one has finally opened.




Please provide any additional information below. Attach a screenshot if
possible.

I encounter this behaviour both on my Windows Vista machine at home and on my Windows 7 machine at work.

UserAgentString: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.106 Safari/535.2
 
Showing comments 142 - 241 of 241 Older

Comment 142 by wnit...@gmail.com, Mar 7 2016

same here, browser is almost unusable...

Comment 143 by stepheni...@gmail.com, Mar 10 2016

**MY FIX**
As previously stated by others, CHECK YOUR EXTENSIONS!!!!

**********

I was having this issue for several days, then I decided to finally try disabling all of the extensions (under "menu" >> "more tools" >> "extensions").

Once I did that IT FIXED MY PROBLEM. I then went through the list and re-enabled them in small chunks at a time. I used two other tabs with Gmail and Google Drive open and tested it each time with the upload/attachment buttons. I found the offending extension to be a User-Agent Spoofer/Switcher I had downloaded a while back.

Comment 144 by brucedaw...@chromium.org, Mar 10 2016

What was the exact extension that you found was causing problems for you?

Comment 145 by rdsmith@chromium.org, Mar 29 2016

Labels: -Needs-Feedback
Removing Needs-Feedback; that seems very stale.  I think this issue was concluded fixed by disabling extensions?

Comment 146 by rdsmith@chromium.org, Mar 29 2016

Cc: rdsmith@chromium.org

Comment 147 Deleted

Comment 148 by steven.j...@gmail.com, Mar 29 2016

No, that did not fix it for me. I eventually reinstalled Chrome entirely. I'm still having DNS issues, but no clue whether or not that is related. Download issues are solved though.

I also believe people higher up commented having tried to disable extensions, which did not work for them.

Comment 149 by davidben...@gmail.com, Jun 22 2016

I disabled all my extensions, but it's still taking 5+ seconds for the save as dialog box to open.
profile.json
3.0 MB View Download

Comment 150 by brucedaw...@chromium.org, Jun 22 2016

I can't load the profile.json file into chrome://tracing. Can you clarify how you created it?

Also, please consider recording and sharing an ETW trace - directions are here:

https://randomascii.wordpress.com/2015/09/01/xperf-basics-recording-a-trace-the-ultimate-easy-way/

Comment 151 by radic...@gmail.com, Aug 31 2016

Im in China (so no google), and checking the tracing view revealed that there is a call for every upload dialog(???) to sb-ssl.google.com more precisely https://sb-ssl.google.com/safebrowsing/clientreport/download?key=AIzaSyBOti4mM-6x9WDnZIjIeyEU21OpBXqWBgw

after blocking sb-ssl.google.com in the host file everything was fast again.

Comment 152 by asvitk...@chromium.org, Aug 31 2016

Cc: mattm@chromium.org k...@chromium.org
+mattm +ktam

I guess sb-ssl.google.com is SafeBrowsing - and it being blocked in China causes Chrome to wait for the request to time out before showing the upload dialog? Seems like this is a bad experience for our users there, so adding Matt from SafeBrowsing and Kingston re: China. Not sure if this area has been discussed already.

Comment 153 by mattm@chromium.org, Aug 31 2016

Cc: nparker@chromium.org
+nparker (re: comment >=151)

Safebrowsing shouldn't have anything to do with uploads. From the url I'm sure they meant downloads. I don't recall where in the process the save-as dialog is shown but I could believe it happens after the safebrowsing check.
We've occasionally had bugs filed related to safebrowsing requests timing out in China. I don't have a great idea for what to do about it though.

Comment 154 by radic...@gmail.com, Sep 1 2016

Hi, 

Should not do, yet it does :). It is an upload dialog with an accept attribute: <input type="file" accept="image/*">, without the accept attr. it is indeed free of Safebrowsing check. Shall I open a new ticket?

Comment 155 by nparker@chromium.org, Sep 1 2016

I don't know what could be going on w/ uploads, but for downloads, I expect there would be a delay as it tries to talk to Safe Browsing inline with the download.  This is WAI since the protection provided is usually worth some wait, assuming it eventually succeeds.

ktam -- It would be a better user experience if we had a "China mode" or some way to detect total loss of connectivity with Google. Then we could optimize this and other places by failing fast.

Comment 156 by hetianz...@gmail.com, Sep 12 2016

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.

Comment 157 by fangxing...@gmail.com, Sep 17 2016

ubuntu 16.4 
Version 55.0.2859.0 dev (64-bit)
when click upload file, slow to show dialog

Comment 158 by brian@briansmith.org, Sep 20 2016

OS: Windows 10.
Chrome 53.0.2785.116 m (64-bit)

I notice that one process (probably the main process, since if I kill it, all other processes die) is taking 100% of a CPU core. The Save dialog box takes a *very* long time to come up--30 seconds or more; sometimes, it apparently *never* opens. When that process isn't hogging a CPU core, the Save dialog box opens like normal. This started sometime in the last two weeks. It was working fine previously.

Comment 159 by brian@briansmith.org, Sep 20 2016

BTW, in my case the issue also affects the File Open dialog box the same way, e.g. when clicking the "add attachment" button in GMail, the dialog box won't open at all or it will be delayed by 15+ seconds.

Comment 160 by brian@briansmith.org, Sep 21 2016

I received a suspicious email about this bug, claiming to be from Google Chrome Engineer Bruce Dawson, known previously for his work on Fifty Shades of Grey (2015), White Noise (2005) and Battlestar Galactica: The Plan (2009). Although I don't care much for any of those films, I still want to help debug this issue. The email I received suggested I download UIforETW from https://github.com/google/UIforETW/releases. Bruce, could you please paste in the sha256 digest of the current version of the etwpackage.zip file here? Thanks!

Note that, at least in my case, the normal chrome://tracing mechanism seems to be broken in exactly the same cases that the Open/Save dialog boxes are broken.

Comment 161 by brucedaw...@chromium.org, Sep 21 2016

That was me - the ETW expert (https://randomascii.wordpress.com/) - rather than my namesake the actor in movies that I have never seen.

For release 1.42b the SHA256 is 345E326FCB10BC91E8E7A2681AE5D71C95DA11CAF8F3077CFB5C16620B1405C9. Now I feel like a proper secret agent. It's also possible to build UIforETW from scratch, although that's more of a nuisance and won't automatically install the required Microsoft packages.

Comment 162 by williamp...@gmail.com, Nov 11 2016

I had been struggling with this issue (Open and Save dialogs being extremely slow) on Windows 10, using Chrome stable 54. I tried everything I could think of, and then stumbled across a solution that absolutely, 100% solved the problem for me. I am sure there are some other issues at play here, but this is what solved it for me (likely Windows 10-only, maybe 8/8.1 [never used those]):
- Check the shortcuts in your 'Quick Access' section of Explorer for any network drives that are no longer available, folders that don't exist, etc
- Remove/fix them.
- That's it!

In my case, I worked from home for a short time while preparing our new offices, and my Quick Access still had links in it to parts of a network-mapped cloud drive from the old office. As soon as I removed those, this problem disappeared entirely.

Like I said, I've seen the non Windows 8-10 reports, so I'm sure there are other issues at play, but this is the biggest, most informative thread on this issue I could find, and if my tip happens to help even one person, I'd be glad I shared it.

Thanks for all you do dev team and testers!
Will Presley

Comment 163 by brian@briansmith.org, Nov 11 2016

I suspect that comment #162 also describes my problem. I sometimes have drive letter mappings to network drives that are't available. Unrelated to troubleshooting this issue on my machine, I got rid of the broken mappings and I've not been able to reproduce since.

Comment 164 by labobol...@gmail.com, Nov 12 2016

I'm jumping on the workaround solution wagon.

If your default save folder have lots of files and folders in it, it can also cause it to lock up. The strange thing is, windows do cache this normally so only the first time is slow in other programs but in chrome it doesn't seem to cache it for some reason. It always acts as if it were the first time.

Just tested it with CTRL+S on this page and with only 471 objects it took some time to load/read from the hard drive instead of from the ram (cache) before the save dialog appeared.

One thing that worked form me oddly enough is to disallow software, without admin access, access to read or write to folders 'JumpListIcons' and 'JumpListIcons'. This also solved the issue of tabs not closing immediately but hanging the browser for a while. It doesn't make sense but meh, who needs jumplist icons!

Thanks for sharing your workarounds. I checked just in case for old network drives. No luck there.

Yikes! Reported Nov 10 2011, the tradition continues. It's so bad google added a bot to put old bug reports, that still are valid, in an "icebox" aka hide them away. Shameful.

Comment 165 by nparker@chromium.org, Nov 14 2016

Cc: -nparker@chromium.org

Comment 166 by brucedaw...@chromium.org, Nov 16 2016

That's interesting that restricting access to the JumpListIcons folder improved the situation. There have been some improvements to JumpListIcons in the past year, but the problem with that folder growing without limit has not been fixed yet. However we have somebody working on that issue right now and we expect to have some sort of fix or workaround. It sounds like that might help with this issue.

Meanwhile, if anybody wants to make sure that we fix the particular problems affecting them then the best thing to do is to record an ETW trace and share it with us. Instructions were listed here:

https://bugs.chromium.org/p/chromium/issues/detail?id=103737#c81

Right now we can just guess as to the causes, and it is quite likely that there are multiple causes. An ETW trace, recorded properly (save the trace immediately after the save dialog appears), will almost certainly let us tell exactly what is going on.

Comment 167 by josel...@alsur.es, Nov 30 2016

I am so desesperate with this after over a year with the issue, that I'm about to give up Chrome forever. In my case is Wundows 7 but as I've heard it happens also in 8 and 10. I've tried some of the numerous solution I've read including some of the latest here for JumpListIcons, cleaning Downloads directory, etc, etc

I've done an ETW trace but I am not comfortable with publishing it here as such. I've tried a "Save image as" and a download which left the tab freezed. Can I email it to you in case if of help? Would that be  brucedaw...@chromium.org ?

Thanks.

Comment 168 by brucedaw...@chromium.org, Dec 5 2016

That email address should work. Please feel free to contact me to discuss possibly sharing the ETW trace as this will probably allow me to understand and resolve your problem.

Comment 169 by brucedaw...@chromium.org, Dec 7 2016

BTW, the email address is brucedawson@, if you want to discuss sharing the ETW trace or share it with me only on Google Drive.

Comment 170 by asanka@chromium.org, Dec 8 2016

Labels: Needs-Feedback
Status: Available (was: Unconfirmed)

Comment 171 by brucedaw...@chromium.org, Dec 9 2016

I received the ETW trace (recorded with UIforETW) mentioned in comment #167 and was immediately able to diagnose the problem.

The trace shows that the browser process is CPU bound for at least 49 seconds (the delay started before the trace began). During that time roughly 96% of the CPU time was spent in a device driver called avc3.sys. This is tagged as being "Active Virus Control filter driver", "3.10.7522.4359. RELEASE.  built by: WinDDK" and appears to be part of Bitdefender Antivirus Free Edition. This device driver is being invoked on calls to Windows functions like ReplaceFileW, MoveFileW, and CreateFileW, and it slows them all down, dramatically.

I don't know what Chrome is doing to trigger this but there is almost certainly nothing that we can do to improve the situation. Even if we called these functions ten times less frequently the delay would still be unacceptably long. I would recommend complaining to the creators of this anti-virus program, and you should seriously consider using a different one. If Bitdefender wasn't getting in the way then the file dialog would probably appear 25x faster, maybe even more.

This is not the One True Cause of these file dialog hangs but it is clearly *one* of the causes.

If somebody wants to point Bitdefender to this comment so that they can investigate, and improve their product, that would be helpful. It could be helpful to know what anti-virus software other people who are hitting this problem are using.

TL;DR - Bitdefender is causing Chrome's browser process to run orders of magnitude slower which leads to hangs when bringing up the file dialog. This is one cause of file dialog hangs, and probably causes other problems as well. Extensions or specific web pages may be making things worse.

Comment 172 by miika.ah...@gmail.com, Dec 11 2016

I've failed to provide ETW traces because I had some weird problems with that that I couldn't figure out, so sorry about that. But I've used Avast personally for a long time, and I think they actually fixed whatever was the problem on their end with it since the problem has not been bothersome for a while on my end, though I had attributed that more to enabling the experimental simple cache in Chrome.

Comment 173 by brucedaw...@chromium.org, Dec 16 2016

Regarding comments #167 (and my reply in comment #171) - the large number of writes to the cache file is combining with the anti-virus to make Chrome unresponsive. Understanding why there is so much cache traffic could be helpful. Since much cache traffic results from packets coming from the network it can be helpful to get a net-internals trace. Details are shown here:

https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

Comment 174 by miika.ah...@gmail.com, Dec 20 2016

One instance this happens - that is probably unrelated to most - is if I right click save a very large animated GIF, the dialog appears only After the GIF is downloaded for display. This might happen with other large displayed files that are still in progress of downloading, like progressive JPEG showing low quality version before it finishes. Probably even super large plain text files if you try to save the page, though I have not tested this really. I of course naturally expect Chrome to react immediately and not someday later.

Comment 175 by tsuchiya...@gmail.com, Jan 11 2017

Had this same issue. Problem turned out to be the "JumpListIconsOld" folder in "Appdata\Local\Google\Chrome\User Data\Default\" being corrupted. The "JumpListIcons" folder had reached 1.69GB in size and it's maximum file limit. Since it was unable to transfer files into the "JumpListIconsOld" folder, I believe that's what was causing my downloads to not start and the "Save-As" dialogs to not open for up to 10 minutes.

Installing and running the Canary version of Chrome, which contains a fix for this issue, seems to have solved the problem for me.

Comment 176 by brucedaw...@chromium.org, Jan 11 2017

Cc: chengx@chromium.org
CCing the developer who did the JumpListIcons fix so that they can track this

Comment 177 Deleted

Comment 178 by chengx@chromium.org, Jan 12 2017

As stated in comment #175:

For all the Windows users, if you also experience long waiting time (i.e., chrome is not responding) when you close tabs, then you are very likely having issues with JumpListIcons folder and/or JumpListIconsOld folder.

They are under C:\Users\<USER>\AppData\Local\Google\Chrome\User Data\Default\

You can navigate to these two folders and see if they are accessible and how big they are. If they are inaccessible and/or they are large in size, then they are corrupted for some reason.

FINALLY, please download the Canary version of chrome which contains a fix for the JumplistIcons issue, and see if it also solves your download issue. Your feedback is very important for us to better understand the bugs and our current solutions.

Here is the link for Chrome Canary:
https://www.google.com/chrome/browser/canary.html

Thanks!

Comment 179 by nick.cia...@gmail.com, Jan 18 2017

Cleaning up the downloads folder fixed this for me

Comment 180 by brucedaw...@chromium.org, Mar 27 2017

Cc: sureshkumari@chromium.org
 Issue 686696  has been merged into this issue.

Comment 181 by brucedaw...@chromium.org, Mar 28 2017

Components: Internals>PlatformIntegration
See also  crbug.com/519959 , which may be a duplicate.

Comment 182 by chengx@chromium.org, Mar 28 2017

Labels: OS-Linux

Comment 183 by chengx@chromium.org, Mar 28 2017

I just went though all the comments. This is really a very odd bug. There are certainly multiple causes behind this bug. It appears in both Windows and Linux as of now. There have been a lot of possible workarounds reported. I am doing some short conclusion for the workarounds below, which should be helpful in understanding the multiple causes of this bug.

1. File System related:
a) Clean up the downloads folder, works for 3 users;
b) Delete/Rename JumpListIcons{,Old} directories, works for 3 users;
c) Run CClearner to clear out the cache, etc, works for 1 user;
d) Uninstall Avast anti-virus (mitigated only, not entirely removed), works for 
   1 user.

2. Network related:
a) Install a NAS in the network, works for 1 user;
b) Connect to company's VPN works for 1 user (not a workaround, but proves it is 
   network related);
c) Enable IPV6, works for 1 user;
d) disable the Client for Microsoft Networks in properties of Local Area 
   Connection, works for 1 user;
e) Clear the DNS cache, works for 1 user;
f) Check the shortcuts in your 'Quick Access' section of Explorer for any 
   network drives that are no longer available, folders that don't exist, etc, 
   and remove/fix them, works for 2 users.

3. Others:
a) Rebuilt the operating system, works for 1 user;
b) Creating a new profile (should be Chrome profile), works for 1 user;
c) Update Adobe Flash Player and install Visual C++ Redistributed, works for 1 
   user;
4) Install Chrome x64, works for 1 user;
5) "If you have Chrome maximized, the save file dialog takes a long time to 
   load. If you have Chrome snapped left or right, the save file dialog appears 
   instantly", works for 1 user;
6) Disable all of the extensions, works for 1 user.

Comment 184 by chengx@chromium.org, Mar 28 2017

Following Comment 183,

Roughly, there are 8 users due to File System issues, 7 users due to Network issues and 6 users due to some other reasons. 

Here are more comments on "File System related". JumpListIcons directories, which are Windows specific, are known to have a big performance issue. It can hang the FILE thread for up to minutes during which no other tasks can run on FILE thread, including downloading files of course. Besides, the JumpListIcons bug is highly suspected to be related to the presence of anti-virus scanning, so 1(d) may also be JumpListIcons related. The JumpListIcons bug is under fixing and a lot of progress have been made. For 1(a) that cleaning up the Downloads folder helps, it needs more investigation.

Comment 185 by chengx@chromium.org, Mar 28 2017

Owner: chengx@chromium.org
Status: Assigned (was: Available)
I will start to investigate why "cleaning up the Downloads folder helps", therefore making myself the owner of this bug for now. 

If somebody wants to take care of the Network part, simply leave a comment and go for it. 

For the workarounds in "Others" category as in Comment 183, they are too scattered therefore I will give them low priority for now.

Welcome to share any of your findings and opinions!

Comment 186 by chengx@chromium.org, Mar 28 2017

Cc: -chengx@chromium.org

Comment 187 by chengx@chromium.org, Mar 29 2017

Following Comment 183,

1(b) which is jumplist bug related is also reported in  bug 326358 

https://bugs.chromium.org/p/chromium/issues/detail?id=326358

Comment 188 by chengx@chromium.org, Mar 29 2017

Cc: ananta@chromium.org ssamanoori@chromium.org chengx@chromium.org
 Issue 519959  has been merged into this issue.

Comment 189 by bugdroid1@chromium.org, Apr 6 2017

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/170f1cf7d23ce3e3fb99085042bf68b8772825a1

commit 170f1cf7d23ce3e3fb99085042bf68b8772825a1
Author: chengx <chengx@chromium.org>
Date: Thu Apr 06 22:46:57 2017

Use GUID to generate unique temp file names and retire GetTempFileName

We use GetTempFileName Windows API to generate an unique temp file name
in some scenarios like downloading files.

It is mentioned on MSDN for this API that "Due to the algorithm used to
generate file names, GetTempFileName Windows API can perform poorly when
creating a large number of files with the same prefix. In such cases, it
is recommended that you construct unique file names based on GUIDs." The
reasons why it's doing poorly include it takes a long time to find an
unique name when a lot of names are already in use. This has been proved
by the fact we found this API call takes minutes for some users who have
lots of temp files in their default download directory. Note that the
temp files in the default download directory can be generated by any
software other than Chrome.

This CL retires GetTempFileName and uses GUID to generate unique temp
file names. With GUID, it is almost guaranteed that an unique temp file
name can be generated with a single attempt.

BUG=103737

Review-Url: https://codereview.chromium.org/2788483005
Cr-Commit-Position: refs/heads/master@{#462662}

[modify] https://crrev.com/170f1cf7d23ce3e3fb99085042bf68b8772825a1/base/files/file_util_win.cc

Comment 190 by bugdroid1@chromium.org, Apr 7 2017

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

commit bbf439562c0b21668040b2c10e560f32dcd42048
Author: chengx <chengx@chromium.org>
Date: Fri Apr 07 21:08:08 2017

Remove unnecessary comments in base/files/file_util_win.cc

BUG=103737

Review-Url: https://codereview.chromium.org/2803563008
Cr-Commit-Position: refs/heads/master@{#463001}

[modify] https://crrev.com/bbf439562c0b21668040b2c10e560f32dcd42048/base/files/file_util_win.cc

Comment 191 by ericyue2...@gmail.com, Apr 17 2017

Thanks for the summary from chengx@chromium.org.

The solution of Clean up the downloads folder works form me!

Comment 192 by brucedaw...@chromium.org, Apr 17 2017

Comment 191 - can you tell us how many files you had in the downloads folder? And did you notice anything about the types of files (typically name patterns)? It would be helpful to understand why the temp directory gets so full. It would be especially helpful to know if Chrome is the cause of the excessive files in the temp directory or if Chrome is just a bystander.

Comment 193 by chengx@chromium.org, Apr 17 2017

Re: Comment 191

Thanks! In addition to the questions asked by brucedawson@ in comment 192, can you please confirm which of following scenarios applies to your case?
1) long wait for save file dialog to open "every time" you try to download a file.
2) long wait just for the "first time" you try to download a file, while the save file dialog appears without much delay for the following download attempts.

Comment 194 by bugdroid1@chromium.org, Apr 19 2017

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4cb75df89a5fabfb4a83717cdc0f9289eb3b0596

commit 4cb75df89a5fabfb4a83717cdc0f9289eb3b0596
Author: chengx <chengx@chromium.org>
Date: Wed Apr 19 00:36:18 2017

A tool to evaluate methods in creating temp files

This "CreateTempFilesPerfEval" tool is to compare the time cost of
creating temporary files between using GetTempFileName Windows API and
using the GUID-based method, especially when there are already tens of
thousands of temp files in the target directory.

Sample results from a corp desktop (Windows 10 Enterprise, version
1511) are recorded in GetTempFileNamePerfExample.txt and
GuidPerfExample.txt in this CL. It shows the time cost of creating
every 500 temp files until there are 65535 temp files created in a
directory for each method. The last row shows the time cost of
creating the very last 35 temp files. Note that GetTempFileName can
create at most 65535 files in a single directory.

The sample results (the last row ommited) are also plotted in
https://docs.google.com/spreadsheets/d/1j5nHneABic4-Ziz7KjjXPAbvr2aERyZB0qwbLYqyKGE/edit#gid=0

From the data/figure, we can see that GetTempFileName is working fine
when the amount of temp files in the folder is under ~36000. It takes
~400 ms to create 500 temp files. However,
1) As the temp files accumulate to 36500, it performs ~4x worse;
2) As the temp files accumulate to 52000, it performs ~9x worse;
3) As the temp files accumulate to 60000, it performs ~15x worse;
4) As the temp files accumulate to 64500, it performs ~50x worse;
5) As the temp files accumulate to 65000, it performs ~110x worse;
   -- Now it takes 43+ seconds to create 500 temp files.
6) As the temp files accumulate to 65500, it performs ~1570x worse;
   -- It takes 44+ seconds just to create the remaining 35 temp files.

In comparison, creating temp files using GUID-based method doesn't
have this performance issue. It always takes 400 ms ~ 500 ms to create
500 temp files. The time complexity of GUID-based method for creating
temp files is O(1) w.r.t the amount of existing temp files in the
target directory.

BUG= 711534 ,103737

Review-Url: https://codereview.chromium.org/2810333008
Cr-Commit-Position: refs/heads/master@{#465438}

[add] https://crrev.com/4cb75df89a5fabfb4a83717cdc0f9289eb3b0596/tools/win/CreateTempFilesPerfEvaluation/.gitignore
[add] https://crrev.com/4cb75df89a5fabfb4a83717cdc0f9289eb3b0596/tools/win/CreateTempFilesPerfEvaluation/CreateTempFilesPerfEval.cc
[add] https://crrev.com/4cb75df89a5fabfb4a83717cdc0f9289eb3b0596/tools/win/CreateTempFilesPerfEvaluation/CreateTempFilesPerfEval.sln
[add] https://crrev.com/4cb75df89a5fabfb4a83717cdc0f9289eb3b0596/tools/win/CreateTempFilesPerfEvaluation/CreateTempFilesPerfEval.vcxproj
[add] https://crrev.com/4cb75df89a5fabfb4a83717cdc0f9289eb3b0596/tools/win/CreateTempFilesPerfEvaluation/GetTempFileNamePerfExample.txt
[add] https://crrev.com/4cb75df89a5fabfb4a83717cdc0f9289eb3b0596/tools/win/CreateTempFilesPerfEvaluation/GuidPerfExample.txt
[add] https://crrev.com/4cb75df89a5fabfb4a83717cdc0f9289eb3b0596/tools/win/CreateTempFilesPerfEvaluation/ReadMe.txt

Comment 195 by bj1...@gmail.com, Jul 19 2017

I tried several items on the list one by one from Comment 183.  With no luck at all.

I google searched again and found the suggestion to 'disable hardware acceleration' in Google Chrome.  Instantly this resolved this problem!!!

I hope this targets the bug and helps others :

http://www.tomshardware.com/answers/id-1862571/google-chrome-slow-opening-pages-upgrade.html

Comment 196 by chengx@chromium.org, Jul 28 2017

Re: comment #195, thanks for sharing this!

Comment 197 Deleted

Comment 198 by chengx@chromium.org, Jul 28 2017

I think it's worthwhile to update the initial conclusion for the workarounds I posted in comment #183 given the new inputs I have got now.

1. File System related:
a) Clean up the downloads folder, works for 4 users;
   - My comments: before trying this, please please take a quick look at how many files you had in the downloads folder? And if you can find anything about the types of files (typically name patterns)
b) Delete/Rename JumpListIcons{,Old} directories, works for 3 users;
   - My comments: the JumpList bug is completed fixed in Chrome version of 60 which is in release now, so it won't be a cause anymore.
c) Run CClearner to clear out the cache, etc, works for 1 user;
d) Uninstall Avast anti-virus (mitigated only, not entirely removed), works for 
   1 user.

2. Network related:
a) Install a NAS in the network, works for 1 user;
b) Connect to company's VPN works for 1 user (not a workaround, but proves it is 
   network related);
c) Enable IPV6, works for 1 user;
d) disable the Client for Microsoft Networks in properties of Local Area 
   Connection, works for 1 user;
e) Clear the DNS cache, works for 1 user;
f) Check the shortcuts in your 'Quick Access' section of Explorer for any 
   network drives that are no longer available, folders that don't exist, etc, 
   and remove/fix them, works for 2 users.

3. Others:
a) Rebuilt the operating system, works for 1 user;
   - My comments: maybe the last thing to try
b) Creating a new profile (should be Chrome profile), works for 1 user;
   - My comments: I think very likely this is JumpList related. Each profile has its own JumpList, so creating a new profile gives a new and healthy JumpList.
c) Update Adobe Flash Player and install Visual C++ Redistributed, works for 1 
   user;
4) Install Chrome x64, works for 1 user; 
   - My comments: could be JumpList related, as this gives you a new and healthy JumpList as well.
5) "If you have Chrome maximized, the save file dialog takes a long time to 
   load. If you have Chrome snapped left or right, the save file dialog appears 
   instantly", works for 1 user;
6) Disable all of the extensions, works for 1 user.
7) [New] Disable hardware acceleration. http://www.tomshardware.com/answers/id-1862571/google-chrome-slow-opening-pages-upgrade.html

Comment 199 by mich...@stickycode.net, Aug 3 2017

I've got this on Chromium Version 59.0.3071.109 (Developer Build) Built on Ubuntu , running on Kubuntu 17.04 (64-bit)

99% certain it did not on 58

Comment 200 by mich...@stickycode.net, Aug 3 2017

I very rarely restart as this is a laptop, and a restart fixed the slowness. Its not clear whats different after the restart.

Before the restart i tried
* fiddling with hardware acceleration
* turning off all extensions
* using guest
* using a new profile
* cleaning downloads folder
* changing themes - was trying to switch from KDE but dont' think its possible on kubuntu
* tried altering KDE themes and settings around the dialog

After the restart the tmp looks about the same, 

the only other thing I did was clean up empty Chrome folders in the KWallet, I think they are from partially created profiles or maybe incognito or guest users. 

Hope you figure this one out

Comment 201 by j.stien...@gmail.com, Oct 25 2017

-> Version 61.0.3163.100 (Developer Build) Fedora Project (64-bit)
-> 1400 files in my $HOME/Downloads
The first file I download: the browser freezes for ~30s, and I hear the hard drive working a lot. Next downloads: work instantaneously.
I don't want to delete my cache, so didn't try this.
I tried a "fdisk.ext4 -D" to rebuild the directory index of the filesystem -> no acceleration. But now the command "ls" in my terminal is almost instantaneous. 
I also tried to mount the Downloads directory via "mcachefs" -> no acceleration.
It looks like the browser is reading the whole folder before writing a new file.

Comment 202 by tokenbin...@gmail.com, Nov 3 2017

[d) disable the Client for Microsoft Networks in properties of Local Area 
   Connection, works for 1 user]  - This worked for me too , was driving me mad, thank you for solution.

Comment 203 by badbrows...@gmail.com, Jan 23 2018

This bug was reported in 2011 and it seems to still be very alive. Never happened on any other browser.

Is this place for reporting the bugs to chromium devs and get them fixed or just a place to discuss our favorite bugs?

Comment 204 Deleted

Comment 205 by miika.ah...@gmail.com, Jan 24 2018

As comment #198 pointed out, there's many reasons leading to the same bug and with inconsistent solutions. But I have to agree, chromium devs have odd priorities that seem to favor new features over fixing basic functionality.

Comment 206 by brucedaw...@chromium.org, Jan 31 2018

Unfortunately we can't reproduce this problem so we don't know what to fix. And, there are probably multiple causes, many of which have (in the past) turned out to be configuration issues on user machines.

As I offered before, one option for any motivated Windows users, if website delays and JumpListIcons don't seem to be the problem, is to record and share an ETW trace. This requires installing Windows Performance Toolkit and using wprui to record a trace. Some details are given here: https://randomascii.wordpress.com/2013/04/20/xperf-basics-recording-a-trace-the-easy-way/

I'd be happy to look at traces that capture the period from the mouse-click to the dialog appearing in order to understand what is happening. I have a pretty good track record for figuring out unreproducible performance problems based on ETW traces so if you are on Windows and seeing this problem when sharing a trace will probably lead to a fix for your specific case.

Comment 207 by k...@chromium.org, Feb 15 2018

Cc: -k...@chromium.org

Comment 208 by rdsmith@chromium.org, Feb 17 2018

Cc: -rdsmith@chromium.org

Comment 209 by hugovang...@gmail.com, Feb 20 2018

FWIW I am observing similar symptoms in a different situation, so have a sneaking suspicion those could perhaps be related.

I am observing this on two different machines running Kubuntu 16.04.3 LTS: After Chrome has been running for a few days, *any* file related dialog (be it "Open file", or "Save file") no longer appear in a timely manner. It takes up to a minute, perhaps even longer. Multiple clicks will eventually open multiple dialogs. 

For me, does not appear to be related to the number of files in Downloads folder, as one machine has a shedload of files, and the other machine just 20 files in there.

(I have been observing this for about 6 months. I just happened to run into the issue again a few minutes ago, decided to search, and found this bug report and thought perhaps my info could be somehow useful.)

Comment 210 by davidbienvenu@chromium.org, Mar 21 2018

Owner: davidbienvenu@chromium.org

Comment 211 by jaleno...@gmail.com, Mar 23 2018

This just happened on two of my laptops, was just now able to fix it by clearing chrome://downloads/ (I think I never ever cleared this before, so the list was quite long), trying the same thing on the other laptop later...
Version 65.0.3325.181 (Official Build) (64-bit) on Windows 10 Pro 1709 16299.309

Comment 212 by davidbienvenu@chromium.org, Apr 25 2018

There are a lot of variations of slowness opening the save file dialog described here:

Very slow the first time after launch, quick afterwards (initial report)
Slow every time
Slow every time after leaving the browser open for days

And some different underlying causes:
Networking issues that cause the Windows save as dialog to be slow to come up. This is a general Windows problem. Note that Firefox dropped support for non-native file save as dialogs so I would expect it to have the same problems, when the issue is in the Windows dialog itself.

Malware/AV software

large number of downloads in about:downloads - clearing the list helps some users, which implies it's related to the way Chrome keeps track of its downloads that's the issue, not the download folder contents.

Adding metrics could help. In particular, stats about the time it takes from when we decide to put up the save as dialog to when we make the call to invoke the system file dialog, and if possible, the time it takes for the OS to put up the dialog. 

And for Windows, ETW traces would be very helpful, per https://bugs.chromium.org/p/chromium/issues/detail?id=103737#c206

Comment 213 by davidbienvenu@chromium.org, Apr 25 2018

 Issue 721721  looks similar to comment #209, i.e., another case of slowdown after leaving the browser open for a long time, also on Linux, though Linux users are more likely to leave apps running for long times.

Comment 214 Deleted

Comment 215 Deleted

Comment 216 Deleted

Comment 217 by virtuate...@gmail.com, May 2 2018

Clean up your downloads file and re-check again! 

I had a similar issue and it was taking up to an entire minute for my spare exchange to open. In the wake of erasing or moving more than 1,000 records my spare as time is totally typical. http://www.virtuatechnologies.com/internet-things.html

Comment 218 by brucedaw...@chromium.org, May 2 2018

I wonder if existence checks for previously downloaded files are taking a long time? chrome://downloads/ lists all of the files that have been downloaded and there certainly are times when an existence check is done. This list of files can be downloaded. Maybe some people who can reproduce this problem could try clearing this list (from the three vertical dots in the top-right corner of the page) to see if that helps.

Comment 219 Deleted

Comment 220 Deleted

Comment 221 by davidbienvenu@chromium.org, May 2 2018

There are definitely reports where clearing the download list fixes the issue. The question is why when and why we do an existence check before bringing up the file save as dialog, and why it's so expensive for some users.

Comment 222 by chengx@chromium.org, May 2 2018

>> when and why we do an existence check before bringing up the file save as dialog?

AFAICT, before bringing up the dialog, it needs to check if the name of the file-to-download has already been taken in the download folder. If it does, it will add a numeric suffix to the file name.

Comment 223 by davidbienvenu@chromium.org, May 2 2018

Right, but unless you've saved the same file name over and over again, that's O(1). Clearing the downloads list from the about:downloads page doesn't remove the files from the download directory; it just removes them from Chrome's download list, so I thought the existence check Bruce was referring to was for all the entries in the download list.

Comment 224 by chengx@chromium.org, May 2 2018

That's possible. 

FYI, in Comment 198, some users seemed to have fixed this issue by merely cleaning up the download folder. However, I am not sure how much we should reply on this information.

Comment 225 by chengx@chromium.org, May 3 2018

According to local tests, removing the files in the download directory will mark the corresponding items in chrome://downloads/ "removed".

Comment 226 Deleted

Comment 227 Deleted

Comment 228 Deleted

Comment 229 Deleted

Comment 230 Deleted

Comment 231 Deleted

Comment 232 Deleted

Comment 233 Deleted

Comment 234 Deleted

Comment 235 Deleted

Comment 236 by brucedaw...@chromium.org, May 8 2018

If the spam comments continue we may have to lock this for external comments. That would be a shame but ten spam comments in a row and fifteen in the last couple of weeks is getting a bit silly.

Comment 237 Deleted

Comment 238 Deleted

Comment 239 Deleted

Comment 240 Deleted

Comment 241 by brucedaw...@chromium.org, May 9 2018

Labels: Restrict-AddIssueComment-EditIssue
Apologies, but due to the huge volume of spam comments I am locking this so that only those with permission to edit the issue can add comments. We are working on this issue.
Showing comments 142 - 241 of 241 Older

Sign in to add a comment