Intent to Ship: global names for FileSystemFileEntry, FileSystemDirectoryEntry and friends

[Joshua Bell]

This is a weird one (redux)...

Contact emails

jsb...@google.com

Spec

https://wicg.github.io/entries-api/ - retroactively documents the now de facto standard.

Summary

The API was implemented in Chrome years ago following parts of the (now deprecated) File API: Directories and System (https://dev.w3.org/2009/dap/file-system/file-dir-sys.html). Both Microsoft Edge and Mozilla Firefox are implementing the subsets documented in "File and Directory Entries API" for compatibility with Chrome in supporting "Directory Upload" scenarios (think: Drive, OneDrive, DropBox, etc). The types as implemented in Chrome are:

• DOMFileSystem
• Entry
• FileEntry
• DirectoryEntry

One particular oddness is present in the Chrome implementation: the types are marked as [NoInterfaceObject]. That means you can't write code referring to the type (e.g. `e instanceof FileEntry`, `FileEntry.prototype.xyz`, etc). This is an anomaly for modern APIs on the platform, where types (even without constructors) are exposed on the global namespace.

 

Per previous discussion [1] [2]

[1] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/_6Euwqv366U

[2] https://github.com/WICG/entries-api/issues/6 

... the desire is to (a) rename the types and (b) and drop [NoInterfaceObject] so the types can be referenced by name:

• DOMFileSystem → FileSystem
• Entry → FileSystemEntry
• FileEntry → FileSystemFileEntry
• DirectoryEntry → FileSystemDirectoryEntry

We'd update the spec at the same time. Otherwise, there is no behavior change.

The motivation for this is consistency, avoid baking more "webkitXYZ" into the platform (see below), and looking towards future APIs that may be built on these - and being able to polyfill them.

Link to “Intent to Implement” blink-dev discussion

The types have been implemented since 2012 or so.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

Nope. (There's probably something up on HTML5Rocks that demos the types, but the [NoInterfaceObject] thing/instanceof tests are not terribly exciting on their own)

Interoperability and Compatibility Risk

Compat:

The risk is that adding these names to the global namespace breaks pages - e.g. relying on window.FileSystem *not* existing.

HTTPArchive (2016-08-01) turns up:

• 0 hits on FileSystemEntry
  
• 0 hits on FileSystemFileEntry
  
• 0 hits on FileSystemDirectoryEntry
  

There is literally one unique hit each for "window.FileSystem" and "var FileSystem" and they look safe in context. ("FileSystem" on its own is a common phrase so I didn't bother looking for that in isolation). Full details are in [2]

Note that the current names are not visible to script except via incantations such as `Object.prototype.toString.call(e)`

Interop:

• Gecko has recently implemented these types with [NoInterfaceObject] because Chrome does. They're in the tree now, so whenever that goes to stable.
  
• Edge has recently implemented these types with a 'webkit' prefix (!!!) because Edge doesn't support [NoInterfaceObject]. No idea on shipping timeline.

There are signals on [2] that if Chrome goes ahead with this change that Gecko and Edge will follow.

OWP launch tracking bug

TBD (will file if this gets approved)

Entry on the feature dashboard

TBD (will file if this gets approved)

[Chris Harrelson]

LGTM

Thanks for the thorough investigation.

--
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+unsubscribe@chromium.org.

[Philip Jägenstedt]

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Joshua Bell]

Minor addition: also rename [NoInterfaceObject] DirectoryReader to FileSystemDirectoryReader. 0 hits on HTTPArchive.

(Still waiting on third L*G*T*M)

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Dimitri Glazkov]

LGTM43

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Addy Osmani]

Non-owner LGTM. Thanks for the redux!

[Joshua Bell]

Just a quick status update on this:

We re-use the Chrome filesystem types not only for directory upload (what's getting cross-browser adoption) but the Chrome-only sandboxed filesystem API (obviously). Perhaps less obviously, the types are also exposed via Extensions and PPAPI and despite the [NoInterfaceObject] declaration there are dependencies on the actual interface names in tests (via Object.prototype.toString.call) in various places, including extensions, devtools, and more things that I probably haven't discovered yet, both directly and via things like closure compiler extern declarations.

So this hasn't gone as quickly or smoothly as I would have liked and is lower priority than some other work. I'm still planning to tackle and haven't given up, but this may require more intricate code surgery than I'd initially expected. (We could potentially fork the impl in Blink to have types specific to directory upload. Too early to say if that's required or not.)

[smaug]

Note, FF will ship the new interfaces in FF51.

-Olli

On 10/04/2016 03:02 AM, 'Joshua Bell' via blink-dev wrote:
> Just a quick status update on this:
>
> We re-use the Chrome filesystem types not only for directory upload (what's getting cross-browser adoption) but the Chrome-only sandboxed filesystem
> API (obviously). Perhaps less obviously, the types are also exposed via Extensions and PPAPI and despite the [NoInterfaceObject] declaration there are
> dependencies on the actual interface names in tests (via Object.prototype.toString.call) in various places, including extensions, devtools, and more
> things that I probably haven't discovered yet, both directly and via things like closure compiler extern declarations.
>
> So this hasn't gone as quickly or smoothly as I would have liked and is lower priority than some other work. I'm still planning to tackle and haven't
> given up, but this may require more intricate code surgery than I'd initially expected. (We could potentially fork the impl in Blink to have types
> specific to directory upload. Too early to say if that's required or not.)
>
>
>
>
> On Wed, Aug 17, 2016 at 2:49 PM, Addy Osmani <ad...@google.com <mailto:ad...@google.com>> wrote:
>
> Non-owner LGTM. Thanks for the redux!
>
> On Friday, 12 August 2016 09:26:22 UTC-7, Joshua Bell wrote:
>
> This is a weird one (redux)...
>
>
> Contact emails
>
> jsb...@google.com
>
>
> Spec
>

> https://wicg.github.io/entries-api/ <https://wicg.github.io/entries-api/> - retroactively documents the now /de facto/ standard.

>
>
> Summary
>
> The API was implemented in Chrome years ago following parts of the (now deprecated) File API: Directories and System

> (https://dev.w3.org/2009/dap/file-system/file-dir-sys.html <https://dev.w3.org/2009/dap/file-system/file-dir-sys.html>). Both Microsoft Edge

> and Mozilla Firefox are implementing the subsets documented in "File and Directory Entries API" for compatibility with Chrome in supporting
> "Directory Upload" scenarios (think: Drive, OneDrive, DropBox, etc). The types as implemented in Chrome are:
>

> * DOMFileSystem
> * Entry
> * FileEntry
> * DirectoryEntry

>
> One particular oddness is present in the Chrome implementation: the types are marked as [NoInterfaceObject]. That means you can't write code

> referring to the type (e.g. `e instanceof FileEntry`, `FileEntry.prototype.xyz <http://FileEntry.prototype.xyz>`, etc). This is an anomaly for

> modern APIs on the platform, where types (even without constructors) are exposed on the global namespace.
>
> Per previous discussion [1] [2]
>
> [1] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/_6Euwqv366U
> <https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/_6Euwqv366U>

> [2] https://github.com/WICG/entries-api/issues/6 <https://github.com/WICG/entries-api/issues/6>

>
> ... the desire is to (a) rename the types and (b) and drop [NoInterfaceObject] so the types can be referenced by name:
>

> * DOMFileSystem → FileSystem
> * Entry → FileSystemEntry
> * FileEntry → FileSystemFileEntry
> * DirectoryEntry → FileSystemDirectoryEntry

>
> We'd update the spec at the same time. Otherwise, there is no behavior change.
>
> The motivation for this is consistency, avoid baking more "webkitXYZ" into the platform (see below), and looking towards future APIs that may
> be built on these - and being able to polyfill them.
>
> Link to “Intent to Implement” blink-dev discussion
>
> The types have been implemented since 2012 or so.
>
>
> Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
>
> Yes.
>
>
> Demo link
>
> Nope. (There's probably something up on HTML5Rocks that demos the types, but the [NoInterfaceObject] thing/instanceof tests are not terribly
> exciting on their own)
>
>
> Interoperability and Compatibility Risk
>
>

> /Compat:/

>
> The risk is that adding these names to the global namespace breaks pages - e.g. relying on window.FileSystem *not* existing.
>
>
> HTTPArchive (2016-08-01) turns up:
>

> * 0 hits on FileSystemEntry
> * 0 hits on FileSystemFileEntry
> * 0 hits on FileSystemDirectoryEntry

>
> There is literally one unique hit each for "window.FileSystem" and "var FileSystem" and they look safe in context. ("FileSystem" on its own is
> a common phrase so I didn't bother looking for that in isolation). Full details are in [2]
>
>
> Note that the current names are not visible to script except via incantations such as `Object.prototype.toString.call(e)`
>
>

> /Interop:/
>
> * Gecko has recently implemented these types with [NoInterfaceObject] because Chrome does. They're in the tree now, so whenever that goes to
> stable.
> * Edge has recently implemented these types with a 'webkit' prefix (!!!) because Edge doesn't support [NoInterfaceObject]. No idea on

> shipping timeline.
>
> There are signals on [2] that if Chrome goes ahead with this change that Gecko and Edge will follow.
>
>
> OWP launch tracking bug
>
> TBD (will file if this gets approved)
>
>

> Entry on the feature dashboard <http://www.chromestatus.com/>

>
> TBD (will file if this gets approved)
>
>
>

> --
> 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+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

[Joe Medley]

Josh,

Does this have a tracking bug or status entry yet?

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org
<mailto:blink-dev+unsubscribe@chromium.org>.

--
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+unsubscribe@chromium.org.

[Joshua Bell]

Tracking bug: https://bugs.chromium.org/p/chromium/issues/detail?id=652814

I'll create a status entry when I have even a vague guess as to milestone.