PSA: Changing File System Access API interaction with the back/forward cache

[Nathan Memmott]

Howdy blink-dev,

In Chromium M121, we will update how the File System Access (FSA) API interacts with the back/forward cache (BFCache). This should only affect the conditions a page can remain in the BFCache. There should be no behavioral changes to the FSA API.

A page can hold FSA locks to files via FileSystemWritableFileStream, FileSystemSyncAccessHandle, and file operations. These FSA locks prevent incompatible concurrent access to a file (e.g. having both a writable and access handle open on a file). A page in BFCache can hold FSA locks and prevent an active (not in BFCache) page from accessing a file. This can be unexpected behavior to a developer/user.

The changes made in Chromium M121 address this issue by evicting a page in BFCache if it allows another page to take an FSA lock. If it doesn't allow another page to take an FSA lock, then the page can remain in BFCache.

This doesn't break any assumptions about concurrent access. An FSA lock is not given out until incompatible FSA locks have been released.

This PR for the whatwg/fs spec defines the behavior in more detail: https://github.com/whatwg/fs/pull/154
 
Thanks,
Nathan

[Vladimir Levin]

On Wed, Dec 20, 2023 at 8:17 PM 'Nathan Memmott' via blink-dev <blin...@chromium.org> wrote:

Howdy blink-dev,

In Chromium M121, we will update how the File System Access (FSA) API interacts with the back/forward cache (BFCache). This should only affect the conditions a page can remain in the BFCache. There should be no behavioral changes to the FSA API.

A page can hold FSA locks to files via FileSystemWritableFileStream, FileSystemSyncAccessHandle, and file operations. These FSA locks prevent incompatible concurrent access to a file (e.g. having both a writable and access handle open on a file). A page in BFCache can hold FSA locks and prevent an active (not in BFCache) page from accessing a file. This can be unexpected behavior to a developer/user.

The changes made in Chromium M121 address this issue by evicting a page in BFCache if it allows another page to take an FSA lock. If it doesn't allow another page to take an FSA lock, then the page can remain in BFCache.

This might be a misunderstanding in terminology on my part, but is this backwards? If the BFCache page allows an active page to acquire a lock, then it's evicted? Or is it then allowed to stay?

This doesn't break any assumptions about concurrent access. An FSA lock is not given out until incompatible FSA locks have been released.

This PR for the whatwg/fs spec defines the behavior in more detail: https://github.com/whatwg/fs/pull/154
 
Thanks,
Nathan

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAO4d-SusHj7XEePhBqBkvH24Q50KHF%3DhMNOPpK5wkwpGvkwe4g%40mail.gmail.com.

[Nathan Memmott]

Sorry, that was poorly worded. We evict "a page in BFCache if [evicting the page in BFCache] allows another page to take an FSA lock."

For example, a page in BFCache may have a sync access handle open on a file. An active page may attempt to open a writable on that same file. Previous behavior is to reject with a NoModificationAllowedError. The new behavior is to evict the page in BFCache to allow the active page to open the writable.

[Vladimir Levin]

Ah that makes sense! Thank you for explaining!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAO4d-SuFB_G_H%2Bqdq2OhN6Fc3gR5Npy%3D5unk5EB1bJbzvPRtHg%40mail.gmail.com.