+1 to removing on all platforms if the numbers are low enough. But if the compat risk is materially greater on at least one other platform than on Android, I personally could accept removal just on Android as an acceptable first step on the deprecation path.
Rick On Wed, Feb 2, 2022 at 11:58 AM Mike West <mk...@chromium.org> wrote: > 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/CAFUtAY-Yd_Uw0maQXVnwn_Tv6um_ie1zxt6GH3%3DDdQWS9snJow%40mail.gmail.com.
