Some background:
- The *filesystem:* URL scheme was introduced to the *File API:
Directories and System* specification
<https://dev.w3.org/2009/dap/file-system/file-dir-sys.html>, which I
generally refer to as *the old FileSystem API*. This API is only
implemented in Blink (maybe it was in the pre-fork WebKit?). To the best of
my knowledge, it was never shipped in Safari, Firefox, IE, or EdgeHTML.
- The main benefit (for developers) of *filesystem:* URLs over *blob:*
is their indefinite lifetime. Blob URLs only live as long as the frame that
created them. This property made them very attractive for serving
sub-resources stored locally, at a time when we didn't have Service Workers.
- We intentionally left the *filesystem:* URL scheme out of the File
System Access API <https://wicg.github.io/file-system-access/>. Service
Workers have a clear model that works well for both top-level navigation
and sub-resources.
We (the folks maintaining storage APIs in Chromium) would very much like to
deprecate the entire old FileSystem API, beginning with the *filesystem:*
URL scheme. We want to be cognizant of introducing too much stress on the
ecosystem, though -- we just finished removing AppCache from Blink, and
we're planning to focus on WebSQL next. Though, maybe you're saying that
*filesystem:* URLs are worse, and we should tackle them first?
I hope this helps!
Victor
On Tue, Feb 1, 2022 at 1:32 AM Mike West <mk...@chromium.org> wrote:
> I worry that removing `filesystem:` for media elements on Android, while
> maintaining support for other platforms, will end up causing some developer
> confusion without much value for the codebase as a whole (since we need to
> maintain all the exciting bits and pieces of infrastructure). Are the
> numbers you quoted for media elements on those other platforms, or all
> element types? Perhaps we could remove support for media elements on all
> platforms if there's substantial benefit to doing so.
>
> Honestly, I'd prefer that we outline a plan to fully remove `filesystem:`
> if we're not going to support it going forward (+Josh and +Victor). It has
> some pretty complicated effects on the security state of navigations, and
> while we have a reasonable plan for PolicyContainer integration with
> `blob:` URLs, we're still a ways away from doing the same for
> `filesystem:`. Is there a path towards deprecating and dropping support on
> other platforms? The large ChromeOS usage makes me somewhat suspicious that
> this is wrapped up in one Google property or another... have y'all done
> that analysis?
>
> -mike
> On Wednesday, January 26, 2022 at 7:48:54 PM UTC+1 Brianna Goldstein wrote:
>
>> Additionally to follow up on @Chris Harrelson <chris...@chromium.org>'s
>> question on usage - Chrome OS usage is 1.38%, Mac OSX is at 0.12% and
>> Windows is 0.05%. We propose to only remove support for Android here.
>>
>> On Tue, Jan 25, 2022 at 7:13 PM Chris Harrelson <chris...@chromium.org>
>> wrote:
>>
>>> Hi, could you outline the use counter values for other platforms? Also,
>>> is there something special about Android that leads you to want to disable
>>> only there?
>>>
>>> On Tue, Jan 25, 2022 at 1:58 PM Brianna Goldstein <
>>> brgoldst...@chromium.org> wrote:
>>>
>>>> Primary eng (and PM) emails
>>>>
>>>> brgoldst...@google.com, m...@chromium.com <m...@google.com>,
>>>> jadekess...@chromium.com
>>>>
>>>> Explainer
>>>>
>>>> Storage partitioning explainer
>>>> <https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md#storage-apis>
>>>>
>>>> Summary
>>>>
>>>> We propose to remove support for loading media via filesystem:// URLs
>>>> on Android.
>>>>
>>>>
>>>> Motivation
>>>>
>>>> As part of our storage partitioning efforts, we will need to update
>>>> Filesystem URLs to be partitioned by StorageKey rather than by Origin.
>>>> Doing this will add complexity since the entire current codepath on Android
>>>> is not dependent on Blink where StorageKey currently lives. On Android only
>>>> 0.0000001% of URLs loaded by <audio> or <video> use the filesystem:// URL
>>>> scheme and we consider this low enough usage to remove support, rather than
>>>> do the work of partitioning. Note that this removal is only for Android. On
>>>> other platforms there will be no effect and media playback of filesystem://
>>>> URLs will continue to work.
>>>>
>>>> Blink component
>>>>
>>>> Blink>Storage
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage>
>>>>
>>>> Initial public proposal
>>>>
>>>> None
>>>>
>>>> TAG review
>>>>
>>>> None
>>>>
>>>> TAG review status
>>>>
>>>> N/A
>>>>
>>>> Interoperability and Compatibility RiskInteroperability risk:
>>>>
>>>> The filesystem:// URL scheme was never widely adopted and is only
>>>> implemented by Chrome. Therefore there should be no interoperability risks
>>>> associated with this feature depreciation.
>>>>
>>>> Compatibility risk:
>>>>
>>>> This feature is very low usage as only 0.0000001% of URLs loaded by
>>>> <audio> or <video> use the filesystem:// URL scheme. Therefore the expected
>>>> compatibility risk is very low.
>>>>
>>>> Alternative implementation suggestion for web developers
>>>>
>>>> Developers can continue to load media from other schemes (http, https,
>>>> blob, file, etc.).
>>>>
>>>> Usage information from UMA
>>>>
>>>> Android Chrome (Browser App): 0.0000001%
>>>>
>>>> Android Webview: 0.0%
>>>>
>>>> Tracking Bug
>>>>
>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1258029
>>>>
>>>> Entry on the feature dashboard
>>>>
>>>> https://chromestatus.com/feature/5632429577469952
>>>>
>>>> --
>>>> 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+unsubscr...@chromium.org.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALDP-vS2KA47PGLh3YkxqAr9z24nP1_u%2BtvY6eWzqSQgq987cQ%40mail.gmail.com
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALDP-vS2KA47PGLh3YkxqAr9z24nP1_u%2BtvY6eWzqSQgq987cQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP_mGKrEhMzfwrzz1DqaCusAcErOiMA3G0X8ufE%3DNNdJtqWg_A%40mail.gmail.com.
