Thanks for the background, Victor! To your question: I don't think dropping `filesystem:` is more important than dropping WebSQL, but I share your excitement about deprecating the filesystem API.
Brianna, I'm still interested in understanding whether the numbers you posted for other platforms reflect usage in media elements or usage overall. If the numbers for media elements specifically on all platforms are as low as they are on Android, I'd prefer for us to remove usage through media elements everywhere. That seems more consistent and explainable if we can get away with it. -mike On Tuesday, February 1, 2022 at 10:47:45 PM UTC+1 Rick Byers wrote: > Given the plan to deprecate this blink-only technology, it does seem silly > to do extra work to keep this one obscure case working. I agree though that > developer confusion is a potential concern. Perhaps an exception / > window.onerror explaining the reason for the failure to play media is > enough? +1 to having a deprecation plan we can point to for at least the > filesystem: URL, then perhaps this can just be the first step in that plan? > > Rick > > On Tue, Feb 1, 2022 at 12:17 PM Victor Costan <pwn...@chromium.org> wrote: > >> 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 >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP_mGKrEhMzfwrzz1DqaCusAcErOiMA3G0X8ufE%3DNNdJtqWg_A%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/7de04377-0b26-4e2a-a29f-37d909c97274n%40chromium.org.
