Issue metadata
Sign in to add a comment
|
Chrome stores memory that will never be released when taking picture from Camera
Reported by
esteban....@gmail.com,
Apr 28 2016
|
||||||||||||||||||||||||
Issue descriptionSteps to reproduce the problem: 1. Create any scenario as simple as with a "<input type="file" accept="image//*" capture="camera" multiple> " field 2. Upload an image from Documents, check in Settings that Chrome's "Data" memory won't increase. 3. Upload a video from the Camcorder, check in Settings that Chrome's "Data" memory won't increase. 4. Upload a picture taking it directly form the Camera. Chrome's "Data" memory will increase without saving it anywhere. What is the expected behavior? Data memory should not increase if we upload a picture unless we explicitly save it to the local storage. Or at least it should eventually release it. What went wrong? Memory should behave equally when uploading a file from Documents, Camcorder or Camera. Did this work before? Yes Chrome Mobile version 42.0.2311.111 Chrome version: 50.0.2661.89 Channel: stable OS Version: 5.0.2 Flash Version: Shockwave Flash 21.0 r0 Also failed in version 49.0.2623.105
,
May 26 2016
This bug concerns me as well. Thank you for looking into it!
,
May 26 2016
It would be nice to hear if anything can be said concerning the progress of this issue. Of course, if someone would need additional information/testing/... I would be glad to provide.
,
Jun 16 2016
A small project to automatically reproduce this issue can be found here: https://github.com/wdlb/chrome-pictures-storage-issue
,
Apr 27 2017
Any updates on this bug? This is still being an issue for our clients. Or does anybody knows about a possible workaround, eg cleaning the Data memory from Javascript?
,
May 8 2017
,
May 11 2017
mcasas@, are you the right person to look at this?
,
May 11 2017
I think this is a dupe of https://crbug.com/574442 , qinmin@, WDYT?
,
May 11 2017
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by rsgav...@chromium.org
, May 6 2016Status: Assigned (was: Unconfirmed)