Zip Archiver: Opening large zip file multiple times blocks other download operations |
|||||||||
Issue descriptionChrome Version: 66.0.3335.0 (1) Create a big zip file (e.g. 100MB+) on Drive. (2) Go to chrome://dvire-internals (3) Click "Clear local data" button. (4) Open the Files app window. (5) Open the zip file. See "syncing..." message on the bottom left of the window, as well as "Archive is being scanned" in the notification center. (6) Open the zip file again while the syncing is ongoing. (repeat several times) (7) Open a small image file (<1MB, not pinned yet) on Drive. EXPECTED: At step 6, the number of "syncing %d items" notification in the Files app should not increase. At step 7, the image should be loaded soon, or at least after the zip file mount is finished. ACTUAL: At step 6, the number of "syncing %d items" notification in the Files app increases as you open the same zip file again. At step 7, the image doesn't load for a long time. It doesn't load even after the zip file is downloaded and mount is finished. We can also confirm by the In-flight Operations section in chrome://drive-internals like the original issue. Impact to user: User may accidentally do step 6 because there is no feedback while it's downloading a zip file. This will prevent all UI operations accessing online files that are not yet cached.
,
Jan 31 2018
,
Jan 31 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f22c91d34b0eee473c31d80fb9d62b23fc2160b9 commit f22c91d34b0eee473c31d80fb9d62b23fc2160b9 Author: Tatsuhisa Yamaguchi <yamaguchi@chromium.org> Date: Wed Jan 31 16:28:05 2018 Zip Archiver: Prevent duplicated loading when opening ZIP file in Drive. Once loading of an archive has been started, it should not start loading the same file again. Existing logic returns "EXISTS" error via fileSystemProvider API when an archive is already mounted. However, it missed handling of a case where user requested opening the same archive while its loading is ongoing. It typically happens when an archive is on Drive and not yet cached. As a transitive fix, this change reuses the "scanning..." message to indiacte that user need to wait operation finish in such case. Bug: 807254 Test: manually tested on Files app as noted in the bug. Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation Change-Id: I90d5b8b2c157ea40b40ad106bbcb85b1bd022ea7 Reviewed-on: https://chromium-review.googlesource.com/895424 Commit-Queue: Tatsuhisa Yamaguchi <yamaguchi@chromium.org> Reviewed-by: Yuki Awano <yawano@chromium.org> Cr-Commit-Position: refs/heads/master@{#533292} [modify] https://crrev.com/f22c91d34b0eee473c31d80fb9d62b23fc2160b9/chrome/browser/resources/chromeos/zip_archiver/js/app.js
,
Feb 1 2018
,
Feb 1 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/79783791a6e1afea3689c797d7ca57d3477149c8 commit 79783791a6e1afea3689c797d7ca57d3477149c8 Author: Tatsuhisa Yamaguchi <yamaguchi@chromium.org> Date: Thu Feb 01 07:15:49 2018 Zip Archiver: Prevent duplicated loading when opening ZIP file in Drive. Once loading of an archive has been started, it should not start loading the same file again. Existing logic returns "EXISTS" error via fileSystemProvider API when an archive is already mounted. However, it missed handling of a case where user requested opening the same archive while its loading is ongoing. It typically happens when an archive is on Drive and not yet cached. As a transitive fix, this change reuses the "scanning..." message to indiacte that user need to wait operation finish in such case. Bug: 807254 Test: manually tested on Files app as noted in the bug. Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation Change-Id: I90d5b8b2c157ea40b40ad106bbcb85b1bd022ea7 Reviewed-on: https://chromium-review.googlesource.com/895424 Commit-Queue: Tatsuhisa Yamaguchi <yamaguchi@chromium.org> Reviewed-by: Yuki Awano <yawano@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#533292}(cherry picked from commit f22c91d34b0eee473c31d80fb9d62b23fc2160b9) Reviewed-on: https://chromium-review.googlesource.com/897382 Reviewed-by: Tatsuhisa Yamaguchi <yamaguchi@chromium.org> Cr-Commit-Position: refs/branch-heads/3325@{#228} Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369} [modify] https://crrev.com/79783791a6e1afea3689c797d7ca57d3477149c8/chrome/browser/resources/chromeos/zip_archiver/js/app.js
,
Feb 1 2018
,
Feb 2 2018
Your change meets the bar and is auto-approved for M65. Please go ahead and merge the CL to branch 3325 manually. Please contact milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 5 2018
The fix has already been merged for M65.
,
Feb 5 2018
,
Feb 8 2018
Verified on CrOS version 10323.24.0, 65.0.3325.59 dev channel eve and coral robo360 devices. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by yamaguchi@chromium.org
, Jan 30 2018