Open Bug 1820502 Opened 3 years ago Updated 1 year ago

Going from Windows 10 to 11 breaks 'default' storage in ESR

Categories

(Core :: Storage: IndexedDB, defect)

Product:
Core
Component:
Storage: IndexedDB
Version:
Firefox 102
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: tom, Unassigned)

References

Details

Attachments

(4 files)

Several screenshots showing the errors in the console (zip because I can only upload one file)
333.28 KB, application/x-zip-compressed
Details
List of broken origin in `storage/default`
74.71 KB, text/plain
Details
PowerShell script to clean broken origins during logon
2.39 KB, text/plain
Details
www.reddit.com storage-origin that appears to be broken and causes errors in the browser console
15.42 KB, application/x-zip-compressed
Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

We have users that have their profiles stored on a network drive. This allows them to use different PCs with the same everything. Due to ongoing migrations it may happen that they switch between Windows 10 and Windows 11 PCs.

Our setup for Firefox ESR (currently v102.8.0) is exactly the same for all of the PCs regardless of their version. We have seen the same issue with older versions of FF ESR.

Occasionally, our users encounter a broken FF profile after they switched from a Windows 10 PC to a Windows 11 PC. It appears that all the IndexedDB SQLite files (or the folders) under 'storage/default' get locked preventing the browser from correctly displaying certain webpages and extension from working.

Most notably, we see issues with trello.com and web.whatsapp.com, these websites heavily use localstorage to store information. We see the same for (among others) the Bitwarden extension.

Actual results:

In the JS console we always see the following errors (the order is not always the same) for general usage:

IndexedDB UnknownErr: ActorsParent.cpp:565
IndexedDB UnknownErr: ActorsParent.cpp:10233
AbortError: A request was aborted, for example through a call to IDBTransactoin.abort
Unchecked lastError value: Error: An unexpected error occurred
uncaught exception: null

For specific usage (e.g., visiting one of the aforementioned websites) gives the following errors:

QM_TRY failure (ERROR): 'Unavailable failed with resultCode 0x8052000C, resultName NS_ERROR_FILE_NOT_DIRECTORY, context dom::localstorage::FirstOriginInitializationAttempt::Datastore', file dom/localstorage/ActorsParent.cpp:489
QM_TRY failure (ERROR): 'Unavailable failed with resultCode 0x8052000C, resultName NS_ERROR_FILE_NOT_DIRECTORY, context dom::localstorage::FirstOriginInitializationAttempt::Datastore', file dom/localstorage/ActorsParent.cpp:553
QM_TRY failure (ERROR): 'Unavailable failed with resultCode 0x8052000C, resultName NS_ERROR_FILE_NOT_DIRECTORY, context dom::localstorage::FirstOriginInitializationAttempt::Datastore', file dom/localstorage/ActorsParent.cpp:7073

I have attached screenshots of the errors in different settings.

We have been able to fix this for users by temporarily copying all files from storage/default to an external location (can be on the same network drive as their actual profile), restart Firefox and close it, and copy the files back.

Also switching back to a Windows 10 PC resolves the issue. We have not seen the issue occur when the user is only using Windows 10 or Windows 11 machines.

We occasionally also see errors for "TemporaryStorage" (in the QM_TRY failures) but that does not affect the behaviour of the browser.

Expected results:

We would expect a functioning browser when switching from a Windows 10 PC to a Windows 11 PC, as the setup for the roaming profile of the user and Firefox itself is exactly the same across all deployments.

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Product: Firefox → WebExtensions
Product: WebExtensions → Firefox

One thing I forgot to add that I got reminded of through the assignment to WebExtensions. Only removing the "moz-extension+++*" folders from "storage/default" does not resolve the issue. Temporarily solving the issue requires replacing all the directories and files in "storage/default". Hence, I believe this is not an issue specifically related to web extension.

Setting this to Core> Widget: Win32 so that our developers could closely examine this issue. If this is not the right component, please assign a more suitable one. Thanks!

Component: Untriaged → Widget: Win32
Product: Firefox → Core

The underlying issue is probably Win32-specific, but I suspect the Storage group will still be more easily able to diagnose it. Forwarding on to them (at least for now).

Component: Widget: Win32 → Storage: IndexedDB

Among the screenshots I see some -wal/-shm files from SQLite apparently when things go wrong. Does this imply some unclean shutdown?

Flags: needinfo?(jvarga)

I should have annotated the screenshots. The one with the SQLite files compares two active instances of Firefox but with different profiles on Windows 11. On the left side we are using a profile that was previously used on a Windows 10 machine and displays the buggy and broken storage. Besides all the errors it throws, it appears to be unable to correctly open and/or access the SQLite databases (should be apparent by the lack of the -wal/-shm files).

On the right, we are using a profile that was created on a Windows 11 machine (and has never been used on a Windows 10 machine), here we see the normal and correct behaviour of Firefox (the -wal/-shm files being present).

The screenshot is specifically looking at the files that are used by the Bitwarden extension, however, this is visible in all directories under "storage/default" it does not matter whether it is an extension's or a websites' data.

As far as we are aware, it does not matter how the instance of Firefox was shutdown on Windows 10 before being used in Windows 11. We have been able to replicate the buggy behaviour by cleanly shutting down Firefox as well as forcefully killing the process.

This is probably similar to bug 1871799 where we found that a site with a trailing dot was causing a storage initialization failure.
As a first step, we probably need to create a debug build similar to https://treeherder.mozilla.org/jobs?repo=try&revision=e0289b9c51f7af66dbb7819aa3d948d3ce97e65e
https://hg.mozilla.org/try/rev/03f36e47f0efded07189e9c16bea996e0842cc8d
That should give us exact name of the problematic site.

Flags: needinfo?(jvarga)

Hi reporter, it's been quite a while and we shipped several improvements, do you still see the same problem?

Flags: needinfo?(tom)
Severity: -- → S3

We are unfortunately still experiencing the same issue, however, our setup has slightly changed. Towards the end of spring last year we switched from ESR v102.X to the normal Release channel version v115 because in testing we noticed the issue the issue to be less prevalent or non-existent at all.

Now all our systems are using Windows 11 (same version; 23H2 22631.3115) but we still experience the same issue in Firefox (Release channel) v121.0.1. This was also the same for all other versions we deployed between v115 and v121.

Sites where we noticed problematic behaviour due to the "broken" storage include:

  • github.com
  • trello.com
  • web.whatsapp.com

We also experience problems with the Bitwarden extension that cannot load data. Furthermore, it also appears to break the F12 DevTools; opening it can lead to a blank DevTools that can subsequently not be closed (without closing the actual tab). The errors we can see when using the -jsconsole option (multiprocess view) are still the same/similar to a year ago (background.js is part of Bitwarden):

IndexedDB UnknownErr: ActorsParent.cpp:556
UnknownError: The operation failed for reasons unrelated to the database itself and not covered by any other error code. ExtensionStorageIDB.sys.mjs:825
    normalizeStorageError resource://gre/modules/ExtensionStorageIDB.sys.mjs:825
    method chrome://extensions/content/child/ext-storage.js:296
    AsyncFunctionThrow self-hosted:856
Unchecked lastError value: Error: An unexpected error occurred background.js:1
    get moz-extension://b15d0e4a-447d-4d50-be99-196509b5f045/background.js:1

For trello.com the errors provide a bit more information:

QM_TRY failure (ERROR): 'Unavailable failed with resultCode 0x8052000C, resultName NS_ERROR_FILE_NOT_DIRECTORY, context dom::localstorage::FirstOriginInitializationAttempt::Datastore', file dom/localstorage/ActorsParent.cpp:485 2
QM_TRY failure (ERROR): 'Unavailable failed with resultCode 0x8052000C, resultName NS_ERROR_FILE_NOT_DIRECTORY, context dom::localstorage::FirstOriginInitializationAttempt::Datastore', file dom/localstorage/ActorsParent.cpp:509
QM_TRY failure (ERROR): 'Unavailable failed with resultCode 0x8052000C, resultName NS_ERROR_FILE_NOT_DIRECTORY, context dom::localstorage::FirstOriginInitializationAttempt::Datastore', file dom/localstorage/ActorsParent.cpp:688 2
QM_TRY failure (ERROR): 'Unavailable failed with resultCode 0x8052000C, resultName NS_ERROR_FILE_NOT_DIRECTORY, context dom::localstorage::FirstOriginInitializationAttempt::Datastore', file dom/localstorage/ActorsParent.cpp:7043

The broken DevTools produce errors similar to this:

IndexedDB UnknownErr: ActorsParent.cpp:9769
Error in asyncStorage.getItem(): AbortError async-storage.js:98:19
    getItemOnError resource://devtools/shared/async-storage.js:98
Error when attaching target: DOMException: A request was aborted, for example through a call to IDBTransaction.abort. target-command.js:228:15
    _onTargetAvailable resource://devtools/shared/commands/target/target-command.js:228
Error when attaching target: DOMException: A request was aborted, for example through a call to IDBTransaction.abort. target-command.js:770:17
    promises resource://devtools/shared/commands/target/target-command.js:770
IndexedDB UnknownErr: ActorsParent.cpp:556
IndexedDB UnknownErr: ActorsParent.cpp:9769
Error in asyncStorage.getItem(): AbortError async-storage.js:98:19
    getItemOnError resource://devtools/shared/async-storage.js:98
Exception while opening the toolbox AbortError: A request was aborted, for example through a call to IDBTransaction.abort. DOMException: A request was aborted, for example through a call to IDBTransaction.abort. toolbox.js:1058:17
    open resource://devtools/client/framework/toolbox.js:1058
IndexedDB UnknownErr: ActorsParent.cpp:556
IndexedDB UnknownErr: ActorsParent.cpp:9769

We are happy to debug this more (or even run a debug build) but we will need some pointers on how to proceed with that.

Flags: needinfo?(tom)

We see the same problem in Thunderbird, where this prevents our users from sending e-mails (until Thunderbird is restarted or the user signs out of the computer; interestingly this "workaround" never works with Firefox).

Errors from Thunderbird:

IndexedDB UnknownErr: ActorsParent.cpp:557
 
UnknownError: IndexedDB: thunderbird/addons-manager-settings getLastModified() IndexedDB: The operation failed for reasons unrelated to the database itself and not covered by any other error code. RemoteSettingsClient.sys.mjs:532:15
    get resource://services-settings/RemoteSettingsClient.sys.mjs:532
 
UnknownError: IndexedDB: thunderbird/search-config getLastModified() IndexedDB: The operation failed for reasons unrelated to the database itself and not covered by any other error code. RemoteSettingsClient.sys.mjs:532:15
    get resource://services-settings/RemoteSettingsClient.sys.mjs:532
 
UnknownError: IndexedDB: thunderbird/hijack-blocklists getLastModified() IndexedDB: The operation failed for reasons unrelated to the database itself and not covered by any other error code. RemoteSettingsClient.sys.mjs:532:15
    get resource://services-settings/RemoteSettingsClient.sys.mjs:532

UnknownError: IndexedDB: blocklists/addons-bloomfilters getLastModified() IndexedDB: The operation failed for reasons unrelated to the database itself and not covered by any other error code. RemoteSettingsClient.sys.mjs:532:15
services.settings: Error retrieving the getLastModified timestamp from blocklists/addons-bloomfilters RemoteSettingsClient UnknownError: IndexedDB: blocklists/addons-bloomfilters getLastModified() IndexedDB: The operation failed for reasons unrelated to the database itself and not covered by any other error code. RemoteSettingsClient.sys.mjs:402
 
UnknownError: IndexedDB: thunderbird/url-classifier-skip-urls getLastModified() IndexedDB: The operation failed for reasons unrelated to the database itself and not covered by any other error code. RemoteSettingsClient.sys.mjs:532:15
    get resource://services-settings/RemoteSettingsClient.sys.mjs:532
 
NS_ERROR_FILE_NOT_DIRECTORY: Component returned failure code: 0x8052000c (NS_ERROR_FILE_NOT_DIRECTORY) [mozIStorageConnection.setGrowthIncrement] imContacts.sys.mjs:38
    getDBConnection resource:///modules/imContacts.sys.mjs:38
    get resource:///modules/imContacts.sys.mjs:116
    initContacts resource:///modules/imContacts.sys.mjs:1461
    init resource:///modules/imCore.sys.mjs:296
    idleStart resource:///modules/chatHandler.sys.mjs:30
    task resource:///modules/MailGlue.jsm:768
    _scheduleStartupIdleTasks resource:///modules/MailGlue.jsm:803

(...)

// Clicking on 'send':
IndexedDB UnknownErr: ActorsParent.cpp:557
UnknownError: The operation failed for reasons unrelated to the database itself and not covered by any other error code. ExtensionStorageIDB.sys.mjs:825
    normalizeStorageError resource://gre/modules/ExtensionStorageIDB.sys.mjs:825
    method chrome://extensions/content/child/ext-storage.js:296
    AsyncFunctionThrow self-hosted:856
    (Async: async)
    callAsyncFunction resource://gre/modules/ExtensionCommon.sys.mjs:1156
    callAsyncFunction resource://gre/modules/ExtensionChild.sys.mjs:737
    callAndLog resource://gre/modules/ExtensionChild.sys.mjs:708
    callAsyncFunction resource://gre/modules/ExtensionChild.sys.mjs:736
    stub resource://gre/modules/Schemas.sys.mjs:2897
    <anonymous> moz-extension://65e0ae11-a0c4-4f96-808e-b4fd085f7235/background.js:8
    apply self-hosted:2366
    applySafeWithoutClone resource://gre/modules/ExtensionCommon.sys.mjs:635
    fire resource://gre/modules/ExtensionChild.sys.mjs:836
    withHandlingUserInput resource://gre/modules/ExtensionCommon.sys.mjs:113
    recvRunListener resource://gre/modules/ExtensionChild.sys.mjs:839
    _recv resource://gre/modules/ConduitsChild.sys.mjs:77
    receiveMessage resource://gre/modules/ConduitsChild.sys.mjs:189
Error: An unexpected error occurred undefined
NS_ERROR_UNEXPECTED
Depends on: 1881526

Thank you for the improved logging in the FF 125 release. We are currently in the process of collecting statistics on which origins are broken and hope to share it in this ticket next week.

Based on our current understanding of the issue, we do not see a pattern in the reported origins. They appear to be "random" and even if multiple users always use the same origins there is no guarantee they break for all users. At the point where Firefox becomes unusable* to our end-users we see only 10-12 broken origins.

*) Unusable here means among other things: websites randomly break, CSP randomly fails, website completely stop loading, and dev tools opens blank and cannot be closed.

Sorry for the delay in responding with the list of broken origins, our privacy officers had to check the list before we could share it. The list contains deduplicated data from about 300 users over a 6-month period.

Based on the data in the list, we cannot draw any conclusion about why the storage is broken. It seems to be completely random and after between 3-10 origins break (this is lower than the 10-12 I communicated earlier), all sorts of things break in Firefox. In many cases, the extensions we use (Bitwarden and uBlock Origin) seem to be one of the first to break, but we've also often seen plenty of people where this was precisely not the case.

The list (see origins.txt) contains on one line the name of the folder in storage/default and then between () the subfolder in which the SQLite files were located, rendering the specific origin ineffective. For example:

https+++developer.mozilla.org (idb)

Would mean that the SQLite files in the idb subfolder were broken of https+++developer.mozilla.org.

Given that it is not clear to us what is causing this not to work (all our computers are now on Windows 11) we have resorted to automatically cleaning broken origins during logons on the computer. We use the following script for this: FF-storage-fixer.ps1 (gist.github.com), I have also attached a copy of it.

(In reply to Tom Udding from comment #12)

Would mean that the SQLite files in the idb subfolder were broken of https+++developer.mozilla.org.

Thank you a lot for providing the list of broken origins. Would it possible to also include the information about error code, source file name and source line number ?

For example:

QM_TRY failure (ERROR): 'Unavailable failed with resultCode 0x8052000C, resultName NS_ERROR_FILE_NOT_DIRECTORY, context dom::localstorage::FirstOriginInitializationAttempt::Datastore', file dom/localstorage/ActorsParent.cpp:485

error code is NS_ERROR_FILE_NOT_DIRECTORY, source file name is dom/localstorage/ActorsParent.cpp and source file line is 485

(In reply to Jan Varga [:janv] from comment #15)

Thank you a lot for providing the list of broken origins. Would it possible to also include the information about error code, source file name and source line number ?

Most certainly, although the errors appear to have become a bit more concise than those I shared earlier. We are currently on ESR 128.0 and affected users can see errors in three separate scenarios:

  1. General usage, normal browsing:
AbortError: IndexedDB: main/tippytop getLastModified() IndexedDB:  execute() A request was aborted, for example through a call to IDBTransaction.abort. RemoteSettingsClient.sys.mjs:529:15
IndexedDB UnknownErr: ActorsParent.cpp:558
IndexedDB UnknownErr: ActorsParent.cpp:9671
  1. Using the developer tools (opens blank if the errors below occur):
IndexedDB UnknownErr: ActorsParent.cpp:9671
Error in asyncStorage.getItem(): AbortError async-storage.js:98:19
Exception while opening the toolbox AbortError: A request was aborted, for example through a call to IDBTransaction.abort. DOMException: A request was aborted, for example through a call to IDBTransaction.abort. toolbox.js:1100:17
IndexedDB UnknownErr: ActorsParent.cpp:558
  1. Browsing websites that (appear to) heavily utilise local storage (e.g. github.com during code selection):
Uncaught NS_ERROR_FILE_NOT_DIRECTORY:
Error while calling actor 'localStorage's method 'getStoreObjects' NS_ERROR_FILE_NOT_DIRECTORY:
NS_ERROR_FILE_NOT_DIRECTORY:

When enough origins stop working (around the 3-10 I indicated), we see the following errors:

QM_TRY failure (ERROR): 'Unavailable failed with resultCode 0x8052000C, resultName NS_ERROR_FILE_NOT_DIRECTORY, context dom::localstorage::FirstOriginInitializationAttempt::Datastore', file dom/localstorage/ActorsParent.cpp:485
QM_TRY failure (ERROR): 'Unavailable failed with resultCode 0x8052000C, resultName NS_ERROR_FILE_NOT_DIRECTORY, context dom::localstorage::FirstOriginInitializationAttempt::Datastore', file dom/localstorage/ActorsParent.cpp:509
QM_TRY failure (ERROR): 'Unavailable failed with resultCode 0x8052000C, resultName NS_ERROR_FILE_NOT_DIRECTORY, context dom::localstorage::FirstOriginInitializationAttempt::Datastore', file dom/localstorage/ActorsParent.cpp:688
QM_TRY failure (ERROR): 'Unavailable failed with resultCode 0x8052000C, resultName NS_ERROR_FILE_NOT_DIRECTORY, context dom::localstorage::FirstOriginInitializationAttempt::Datastore', file dom/localstorage/ActorsParent.cpp:7032

At that point, we almost always have to use the PowerShell script to clear the broken origins. Sometimes we can remove specific broken origins if they come up in the browser console, but that 'warning' does not always appear (but I have seen them since they were introduced in FF 125). A recent example of this is:

QM_TRY failure (WARNING): 'Unavailable, storage-origin https://www.reddit.com, context dom::quota::FirstInitializationAttempt::TemporaryStorage', file dom/quota/ActorsParent.cpp:2798

I have attached a copy of the affected https+++www.reddit.com folder.

Thanks again for very useful, precise and detailed information.

So it seems this is mostly about this line:
https://searchfox.org/mozilla-esr128/rev/7818a57ec298b7e828445173aec6ac2bcfccae32/dom/localstorage/ActorsParent.cpp#481
SetGrowthIncrement fails with NS_ERROR_FILE_NOT_DIRECTORY

SetGrowthIncrement can only fail with NS_ERROR_FILE_NOT_DIRECTORY if GetDiskSpaceAvailable fails I think:
https://searchfox.org/mozilla-central/rev/4496b3ed9bb535832e4826f09fbcb645b559a32d/storage/mozStorageConnection.cpp#2708

I checked the attached zip for www.reddit.com and the origin directory looks ok

NS_ERROR_FILE_NOT_DIRECTORY is mapped from ERROR_DIRECTORY windows native error code.
The documentation for ``ERROR_DIRECTORY` says "The directory name is invalid."

Could it be that the full path for https+++www.reddit.com somehow is close to limits for a path on windows ?
Some time ago we started using the \\?\ prefix to mitigate problems with long paths on windows.
That should allow 32,767 characters in total while each path component can have 255 chars at maximum.
If the given platform somehow is not able to process the \\?\ prefix, the max total path length is only 260 chars.

If it's not a problem related to path length, it can be a problem with some special characters in the path, but that should also be mitigated by the \\?\ prefix. In that case, you would see a pattern that only specific origin directories cause breakage.

We could try to fix this just by ignoring any errors returned from SetGrowthIncrement, but at this stage I can't say if that's the right fix, because something else can fail if there's a problem with the file path.

BTW, if you can open the origin directory in the windows file explorer then it likely indicates that the file path is ok

(In reply to Tom Udding from comment #16)

QM_TRY failure (WARNING): 'Unavailable, storage-origin https://www.reddit.com, context dom::quota::FirstInitializationAttempt::TemporaryStorage', file dom/quota/ActorsParent.cpp:2798

You can ignore this one because it's just a warning (there can be ERRROR or WARNING in the brackets).

Hm, I just re-read the comment 0 and it mentions that the profile is on a network drive, is that still true ?

Another useful information would be if the breakage is totally permanent or FF works ok when you run it second time or third time.
If it's not permanent, it would probably indicate that there are random network issues.

Could it be related to different SMB versions used on Windows 10 and Windows 11 ?
Have you tried to force Windows 10 to use newer SMB versions ?

(In reply to Jan Varga [:janv] from comment #19)

Could it be related to different SMB versions used on Windows 10 and Windows 11 ?
Have you tried to force Windows 10 to use newer SMB versions ?

Obviously per comment 9, all your system are now using Windows 11, so never mind.

See Also: → 1913357

Hold on, we might have found a bug in file path handling code.

(In reply to Jan Varga [:janv] from comment #21)

Hold on, we might have found a bug in file path handling code.

Could you execute this custom build and make it point to one of those profiles? It is unsigned, but you can see how it was built here - it is basically the current nightly from mozilla-central plus the debug logging.

We are particularly interested to see any message containing GetDiskSpaceAvailable and the concrete path it tries to use.

Thank you!

Flags: needinfo?(tom)

The replies below are in order of the original comments.

(In reply to Jan Varga [:janv] from comment #18)

Could it be that the full path for https+++www.reddit.com somehow is close to limits for a path on windows ?
Some time ago we started using the \\?\ prefix to mitigate problems with long paths on windows.
That should allow 32,767 characters in total while each path component can have 255 chars at maximum.
If the given platform somehow is not able to process the \\?\ prefix, the max total path length is only 260 chars.

If it's not a problem related to path length, it can be a problem with some special characters in the path, but that should also be mitigated by the \\?\ prefix. In that case, you would see a pattern that only specific origin directories cause breakage.

...

BTW, if you can open the origin directory in the windows file explorer then it likely indicates that the file path is ok

This is something we looked at, but even if Windows were to decide not to use \\?\ and fully expand the hostname of the file server, we are well under the limit. And as far as we are aware only ASCII characters appear in the full path (fileserver hostname and usernames are all alphanumeric). There are a few very long origins in the list I gave earlier where the directory name itself is >110 characters that come close to the 256 limit, but should still fit. And then it would also be puzzling as to why the shorter origins (~20 characters in terms of folder name) also have problems while having significantly shorter paths.

(In reply to Jan Varga [:janv] from comment #18)

Hm, I just re-read the comment 0 and it mentions that the profile is on a network drive, is that still true ?

Another useful information would be if the breakage is totally permanent or FF works ok when you run it second time or third time.
If it's not permanent, it would probably indicate that there are random network issues.

Yes, the profiles are still on a network drive. While it is difficult to completely rule out network issues, we strongly believe this is not the cause. Our reasoning being that for all other programs we use (perhaps with the exception of Thunderbird) we do not experience issues. Furthermore, we essentially have a direct link from our workstations to the fileserver limiting outside interference/routing issues.

(In reply to Jens Stutte [:jstutte] from comment #22)

Could you execute this custom build and make it point to one of those profiles? It is unsigned, but you can see how it was built here - it is basically the current nightly from mozilla-central plus the debug logging.

We are particularly interested to see any message containing GetDiskSpaceAvailable and the concrete path it tries to use.

Thank you very much for providing a debug build. We are in the process of deploying it to a select number of users to collect the logs. Due to the weekend, the debug build will not be actively used until after Monday, we then hope to deliver the required data/report on the findings by the end of the upcoming week. If it turns out to be too short of a timeframe, I will let you know as soon as possible and (if available) report on the data in the week of 26 August.

My apologies for getting back to you this late. I was sick for most of September, which significantly delayed our testing with the provided debug build.

Unfortunately, we have not seen the GetDiskSpaceAvailable error while using the debug build. We tested several configurations during October, including enabling and disabling Offline Files in conjunction with the folder redirection/roaming profiles that we already have in place. This does not appear to affect the storage breaking or not breaking.

Since we had the most issues with the Bitwarden extension, we have also tested our deployments without that (also for the normal Firefox build most of our users use). However, we are still seeing the issue (perhaps less frequently but still noticeable).

Recently, we have also started seeing crashes similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1877111. However, we assume that these issues are completely unrelated.

Flags: needinfo?(tom)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: