I tried to play a movie on https://netflix.com but I got the Netflix error 32660. OS: Windows 10, 64 Bit Firefox: 52, 64 Bit I tracked the problem down to the file: FIREFOX-PROFILE/storage/persistent/chrome/.metadata It's 0 KB in size. Workaround/manual fix: If I delete the ".metadata" file and restart Firefox, Netflix works. After deleting the ".metadata" file and playing something on Netflix the following new folder appears: FIREFOX-PROFILE/storage/default/https+++www.netflix.com/ I guess the ".metadata" file maybe somehow blocked the creation of this folder!?!? Note: This is not about MP4/h264 or DRM. Both is completely disabled and I had to make any changes to it to get Netflix running.
Component: Untriaged → Desktop
Product: Firefox → Tech Evangelism
Version: 52 Branch → Firefox 52
2 years ago
platform-rel: --- → ?
Andrew - does storage/persistent/chrome/.metadata belong to you?
Whiteboard: [platform-rel-Netflix] → [platform-rel-Netflix][needsdiagnosis]
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #1) > Andrew - does storage/persistent/chrome/.metadata belong to you? I didn't create any files manually in the Firefox profile folder. (if that's what you mean!?) So I guess Firefox created that file somehow.
Jan thinks we have different code for handling corrupted .metadata in storage/chrome vs. storage/default (for content). He's going to take a look.
Assignee: nobody → jvarga
Component: Desktop → DOM: Quota Manager
Flags: needinfo?(overholt) → needinfo?(jvarga)
Priority: -- → P3
Product: Tech Evangelism → Core
Version: Firefox 52 → 52 Branch
This is now tracked under meta bug 1482662.
Tom, if I remember correctly, the issue is that we don't do metadata recovery for origin directories in storage/permanent directory.
Assignee: jvarga → shes050117
Assignee: shes050117 → nobody
Whiteboard: [platform-rel-Netflix][needsdiagnosis] → [platform-rel-Netflix][needsdiagnosis]DWS_NEXT
I guess I might need to do some experiment and more investigation to understand the real issue behind. Based on the description in comment #0, it seems like the directory metadata file in the permanent repository couldn't be read and it's strange because the size of it was 0 kb. Besides, the reporter mentioned that the workaround is to remove the file, so it means QM was able to recover itself if that strange file didn't exist. Jan advised me that it might be related to metadata recovery for directories in permanent folders. However, by reading the code: The main initialization logic is in EnsureOriginIsInitializedInternal(), it basically does: 1. EnsureStorageIsInitialized 2. EnsureTemporaryStorageIsInitialized 3. EnsureOriginDirectory and InitializeOrigin 1 is related to upgrade storage version. For all the upgrades, they restore the directory metadata files if they couldn't be read. 2 touches the directory metadata, but it only does that for default and temporary repositories. So it's not related to this issue. 3 creates a directory metadata file if the directory of given origin hasn't been created. Also, it grabs information from the persistent origin directory metadata if the directory of given origin was created. If the persistent origin directory metadata fails to be read, then it would be restored in this case. For now, I guess this issue is more like somehow FF couldn't restore the metadata file in the permanent repository (for instance, the metadata file is hold by other applications or os system), but it seems to be unlikely to happen. So, I should confirm the code and the speculation I mentioned above by doing experiments. Anyway, there are no obsolete files involved, so the fix here seems not be a part of the upcoming minor upgrade.
- It seems that the issue happened the schema version reporter's profile was version 0_0 so that comment #0 mentioned "persistent/chrome" rather "permanent/chrome". - I suspect that "persistent/chrome/.metadata" somehow blocked the storage upgrades in EnsureStorageIsInitialized() so that it couldn't be upgraded and the initialization failed because upgradeStroage0_0To1_0 doesn't recover the metadata file for persistent storage. - Will confirm the second item later.
(In reply to Tom Tung [:tt] from comment #7) > - I suspect that "persistent/chrome/.metadata" somehow blocked the storage > upgrades in EnsureStorageIsInitialized() so that it couldn't be upgraded and > the initialization failed because upgradeStroage0_0To1_0 doesn't recover the > metadata file for persistent storage. After looking into the code, I don't think an unreadable metadata can block upgrades even if it's under permanent/persistent repository. Will have a test to verify that tomorrow. Now, I lean to reckon the issue for restoring metadata was fixed in another bug. The test might verify: 1. Initializing (initOrigin()) a normal origin with default type and with a profile that has a broken metadata file under the permanent folder. 2. Initializing (initOrigin()) an origin that storing under the permanent folder and its metadata file was broken. 3. Initializing (init()) an old profile (version 0_0) with a broken metadata in the "persistent" folder. I guess all of these three subtests should succeed.
Assignee: nobody → shes050117
IIUC, I need to check whether an abnormal metadata file living in an origin directory and in the persistent repository break the storage initialization. The storage initialization touches the persistent repository's origin directory metadata files only when it's in an upgrade or origin initialization. However, it seems that current QuotaManager does metadata file recoveries even for persistent type origin directories. I wrote a test (attachment 9022873 [details] [diff] [review]) to verify the behavior of initialization when there is an empty metadata file in the permanent repository. This test verifies three conditions when there is an empty metadata file in a permanent repository: - The upgrades of storage to the newest version don't fail - The initialization of another normal (default) origin doesn't fail - The initialization of that persistent origin doesn't fail If anything wasn't neglected, then that probably means the original issue has been resolved. I tested it locally and all the tests passed. Jan, could you take a look and help me to check if there are some cases that I might miss?
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.