Here are two more questions and one suggestion: 1. It looks like the usage on ChromeOS is an outlier. Is this due to Chrome Apps? Do we have UKM on it? 2. Is a migration to ServiceWorkers a simple drop-in replacement or would it require significant work for a site to adopt? 3. Do you think the larger deprecation is feasible to do over the next year, based on data you have now? If so I wonder if we could go with a deprecation message now and a reverse origin trial & outreach to drive down usage.
On Wed, Feb 2, 2022 at 9:22 AM Brianna Goldstein <brgoldst...@chromium.org> wrote: > Mike, these numbers are for media elements specifically. Since Chrome OS > is > 1% I'd suggest removing `filesystem://` from Android as a first step > in deprecating across platforms rather than leaving the Android path > unpartitioned and then following up with a depreciation path to deprecate > across platforms. > > Brianna > > 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/CALDP-vQNK58p5zxkcaLH554OWRxJCtOoUrUS97HHema2_XG8Wg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALDP-vQNK58p5zxkcaLH554OWRxJCtOoUrUS97HHema2_XG8Wg%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/CAOMQ%2Bw9s7807MJh60tj3%3Dx1PgC4Y%2BkYhCFAuT4fupOw2MbZPUQ%40mail.gmail.com.
