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/CAFUtAY9KMa0Kd_6bh%2BV4ft%2BhmtnDBnzBjQdmy-giKKLs-r1Hkw%40mail.gmail.com.
