Yoav, yeah this is a bit of rarely used legacy, see FileSystemEntry.toURL <https://developer.mozilla.org/en-US/docs/Web/API/FileSystemEntry/toURL>. IIRC we used filesystem URLs in Offline GMail to enable opening email attachments while offline. I think this provided a better UX than blob: URLs because of the existence of a human readable file name, but I can't remember if there were other reasons filesystem: URLs were essential.
It does seem like a wart to me to have filesystem: URLs continue to work everywhere EXCEPT media on Android, but given the very low usage I think I'd be OK considering this an open low-priority bug in the platform to potentially be fixed in the future based on the level of partner demand. Thoughts? Checking the WebView UseCounter is a good idea, but I suspect it'll be very low since I think apps would generally prefer to load resources directly out of the bundle with file: URLs, not the virtual web-only filesystem created by the Filesystem APIs. Rick On Wed, Jan 26, 2022 at 10:49 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > At the risk of piling on with another question: are these URLs different > from `file://` scheme URLs? > > On Wednesday, January 26, 2022 at 11:41:17 AM UTC+1 Daniel Bratell wrote: > >> How confident can we be in the WebView counter? I'd expect this to be >> used more in WebView than on other platforms. >> >> /Daniel >> On 2022-01-26 01:13, Chris Harrelson 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 Risk Interoperability 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/CAOMQ%2Bw_cAggyuYtcNrNrQKT4vEL5iRSp6qMoOEJ8cFvaq6iSpg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_cAggyuYtcNrNrQKT4vEL5iRSp6qMoOEJ8cFvaq6iSpg%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/1f198100-936d-41e3-8952-826c9bb0b9ban%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1f198100-936d-41e3-8952-826c9bb0b9ban%40chromium.org?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-Kyis3iKXB-xAwZqi6OqrG_43UN_EixskVxapcWExzRg%40mail.gmail.com.
