New issue
Advanced search Search tips

Issue 892547 link

Starred by 5 users

Issue metadata

Status: Fixed
Owner:
Closed: Oct 11
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Application Cache size is limited to 5MB

Reported by eldo...@gmail.com, Oct 5

Issue description

UserAgent: 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. Load fail.html
2. The browser tries to load the 6 files of about 1MB specified in the fail.appcache manifest
3. The storage commit fails due to quota exceed

What is the expected behavior?
The commit succeeds.

What went wrong?
The commit fails saying it would exceed quota.

You can try success.html, which loads just 5 of the files in the manifest, remaining under 5MB of total size, and it will succeed.

Did this work before? Yes 70

Does this work in other browsers? Yes

Chrome version: 71.0.3570.0  Channel: canary
OS Version: 10.0
Flash Version:
 
AppCache_test.zip
9.8 KB Download
Components: Blink>Storage>Quota Blink>Storage>AppCache
Labels: -Pri-2 OS-Mac Pri-1
Owner: pwnall@chromium.org
Status: Assigned (was: Unconfirmed)
Thank you very much for the thorough report.

Was able to reproduce the bug on most recent Canary 71.0.3571.0 on Mac. The bug does not reproduce on 69.0.3497.100, so it is definitely a regression.

While reproducing, I also noticed that the "Application Cache" tab under DevTools > Application is populated in M69 but not populated in M71. This might be related to the quota problem, or might be a separate bug.
Labels: RegressedIn-71
The bug does not reproduce on 70.0.3538.45 on Mac, so it is a regression introduced in M71. 

The AppCache tab in DevTools does not update in M70, so that error is unrelated to this bug.
Filed  https://crbug.com/892562  to track the DevTools issue.
Cc: gyuyoung...@lge.com jsb...@chromium.org piman@chromium.org
The root cause is https://crrev.com/c/1203752

At a high level, the approach in  https://crbug.com/824619  seems unfortunate. The bug doesn't have a component (Blink>Storage>AppCache and Blink>StorageQuota come to mind), so it didn't show on our radar. The work introduced a non-trivial AppCache change without adding tests, and without consulting the Storage team. Asides from causing this bug, the approach is most likely incorrect -- reducing disk storage limits is best accomplished in Quota Manager, where the behavior change would apply to all storage APIs.

We're close to branch point, and I think the best path forward is to revert the changes in https://crrev.com/c/1203752 before M71 branches. I'd like to figure out another AppCache crasher before branch point, so I won't have time to explore a better fix. After the branch, we can figure out how to best meet the needs behind the feature.

gyuyoung.kim@: Please reach out to me (pwnall@chromium.org) over the next few days if you need this in M71.
Haven't heard anything, going to start reverting the CLs here.
The root cause was reverted in https://crrev.com/c/1271879
@pwnall, Sorry for late response. I was on a business trip by yesterday. Once I'm going to check what code caused the issue. Thanks and sorry for the inconvenience.
gyuyoung.kim@lge.com: No worries.

Let's discuss in  https://crbug.com/824619  to find a way to get your needs met.
Status: Fixed (was: Assigned)
Checked that the bug does not repro in today's Canary -- 71.0.3576.0

Sign in to add a comment