While others weight in on the specific intent, I'd like to see the addition of handling Response objects (potentially directly from the Cache Storage) API added to Media elements as a replacement for this. Folks shouldn't have to need to install a Service Worker to do this directly, and it would cover many of these use-cases as we look to remove this more globally.
Regards On Tuesday, February 1, 2022 at 1:47:45 PM UTC-8 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/d41f4b0b-daf6-46ba-839e-00839d76bc46n%40chromium.org.
