Issue metadata
Sign in to add a comment
|
JumpListIcons and JumpListIconsOld folders can be filled up causing new tabs to not load anything just waiting
Reported by
labobol...@gmail.com,
Jun 20 2016
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 Example URL: Steps to reproduce the problem: Steps to reproduce this issue is unknown because it can take so long to reproduce. You will need the browser to create 65535 files in the JumpListIcons folder to cause this bug to occur. You will see it as new tabs is in loading state without content and waiting and main chrome process using 100% of the cpu core it's on. For me the folder was ~1.4 GB!!! What is the expected behavior? Chrome to be nice to my hard drive and that edge cases however unlikely are handled properly and __reported to the user and not be silent__ What went wrong? My first suspicion that something was wrong with some software was when the hard drive space continually ticked down to zero. Now I know why! The temporary filename function in chrome have can generate 65535 files in one folder and than it can't generate anymore. Aside from the big hard drive usage and space usage. It will cause all new tabs to wait infinitely for that jump list icon generation to complete. Chrome should be able to clear both JumpListIcons and JumpListIconsOld folders when they each reach a certain number number of files or size. That just one folder takes up ~1.4 GB is unacceptable! Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? No Does this work in other browsers? Yes Chrome version: 51.0.2704.103 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 22.0 r0 There is a related bug somewhere, most likely unfixed, unsure if you have hidden it away as closed, that describe chrome's excessive hard drive usage of writing files to JumpListIcons and JumpListIconsOld folders even when: - chrome is idle. - it's unnecessary, icon not changed, too often, etc. Think of the hard drives! Chrome is killing them and it's environmentally unfriendly (and will piss of chrome users too but you don't seem to care about them).
,
Jun 21 2016
,
Jun 22 2016
"This doesn't seem to be Blink-related." I didn't add the label. I noticed the label 'needs-feedback'. What do you want to know? I see no questions.
,
Jun 23 2016
Thank you for providing more feedback. Adding requester "tkonchada@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
,
Jul 13 2016
Could you please provide a testcase/HTML file to reproduce the issue from test team end.
,
Aug 11 2016
,
Jan 13 2017
Hi, thanks for reporting this bug. Actually this JumplistIcon bug has been there for a while. Since bug 40407 is about the same thing and has the most discussion there, I will merged this one to bug 40407 .
,
Jan 13 2017
Also, I have checked in a fix to this bug. Though I think this can fix this bug (or part of it), I was not able to verify it because I cannot reproduce the bug locally on my machine. This fix is available in the canary version of chrome, not the stable version which you are using now yet. If you can try the canary version and see if you still have this issue, that will help us better understand the bug and the current fix. The canary version of chrome can be downloaded via https://www.google.com/chrome/browser/canary.html You will find "JumplistIcons" folder for canary in a similar path to the one you have trouble with now. Please reply in bug 40407 if you have any feedback to share with us. Thank you! |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by aboxhall@chromium.org
, Jun 20 2016