Intent to Ship: Entry/FileEntry/DirectoryEntry/DOMFileSystem without [NoInterfaceObject]
99 views
Skip to first unread message
Joshua Bell
Aug 10, 2016, 12:19:52 PM8/10/16
to blink-dev
This is a weird one...
Contact emails
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.
One particular oddness is present in the Chrome implementation: the types Entry, FileEntry, DirectoryEntry, and DOMFileSystem 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.
The intent is to drop [NoInterfaceObject] so the types can be referenced by name. Otherwise, there is no behavior change.
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.Entry *not* existing. It's basically impossible to find out without trying.
Interop:
* Mozilla 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.
If Chrome can successfully drop [NoInterfaceObject] here the other browsers will likely follow.
OWP launch tracking bug
TBD (will file if this gets approved)
Entry on the feature dashboard
TBD (will file if this gets approved)
smaug
Aug 10, 2016, 12:33:02 PM8/10/16
to Joshua Bell, blink-dev
Why this change to the ancient bad API? Has anyone actually asked for these interfaces?
And change which makes blink's implementation again different to other implementations.
(I'm still hoping browser vendors could agree on some new reasonable Filesystem API)
-Olli
On 08/10/2016 07:19 PM, 'Joshua Bell' via blink-dev wrote:
> This is a weird one...
>
>
> Contact emails
>
> jsb...@google.com <mailto:jsb...@google.com>
>
>
> Spec
>
> https://wicg.github.io/entries-api/ <https://wicg.github.io/entries-api/> - retroactively documents the now /de facto/ standard.
> 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>.
And change which makes blink's implementation again different to other implementations.
(I'm still hoping browser vendors could agree on some new reasonable Filesystem API)
-Olli
On 08/10/2016 07:19 PM, 'Joshua Bell' via blink-dev wrote:
> This is a weird one...
>
>
> Contact emails
>
>
>
> 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
>
> Summary
>
> The API was implemented in Chrome years ago following parts of the (now deprecated) File API: Directories and System
> Mozilla Firefox are implementing the subsets documented in "File and Directory Entries API" for compatibility with Chrome in supporting Directory Upload.
>
>
> One particular oddness is present in the Chrome implementation: the types Entry, FileEntry, DirectoryEntry, and DOMFileSystem 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
>
>
> One particular oddness is present in the Chrome implementation: the types Entry, FileEntry, DirectoryEntry, and DOMFileSystem are marked as
> [NoInterfaceObject]. That means you can't write code referring to the type (e.g. e instanceof FileEntry, FileEntry.prototype.xyz
> global namespace.
>
>
> The intent is to drop [NoInterfaceObject] so the types can be referenced by name. Otherwise, there is no behavior change.
>
>
> 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 intent is to drop [NoInterfaceObject] so the types can be referenced by name. Otherwise, there is no behavior change.
>
>
> 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
>
>
>
> The risk is that adding these names to the global namespace breaks pages - e.g. relying on window.Entry *not* existing. It's basically impossible to
> find out without trying.
>
>
> /Interop:/
> The risk is that adding these names to the global namespace breaks pages - e.g. relying on window.Entry *not* existing. It's basically impossible to
> find out without trying.
>
>
>
> * Mozilla 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.
>
>
> If Chrome can successfully drop [NoInterfaceObject] here the other browsers will likely follow.
>
>
> OWP launch tracking bug
>
> TBD (will file if this gets approved)
>
>
> Entry on the feature dashboard <http://www.chromestatus.com/>
> * Mozilla 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.
>
>
> If Chrome can successfully drop [NoInterfaceObject] here the other browsers will likely follow.
>
>
> OWP launch tracking bug
>
> TBD (will file if this gets approved)
>
>
>
> TBD (will file if this gets approved)
>
>
> --
> 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>.
Elliott Sprehn
Aug 10, 2016, 12:53:11 PM8/10/16
to Joshua Bell, blink-dev
I don't think we should expose an interface named so generic as "Entry" on the global. Reserving that forever for file system seems weird. I'd prefer we leave that as NoInterfaceObject.
Elliott Sprehn
Aug 10, 2016, 12:54:17 PM8/10/16
to Joshua Bell, blink-dev
Or came up with better names, since the interfaces weren't exposed before it's much lower risk. We could name this superclass something else if it needs to be exposed.
Addy Osmani
Aug 10, 2016, 7:27:54 PM8/10/16
to blink-dev, jsb...@google.com
I would also strongly second the feedback from Elliot. Entry as a global name on window may well cause confusion in the current form. With respect to breakage, was research done on how much usage window.Entry has in the wild?
Joshua Bell
Aug 10, 2016, 7:38:41 PM8/10/16
to Addy Osmani, blink-dev
I inquired with the folks behind window.fetch for how that was done. The response I got was along the lines of "we just hoped real hard".
Since Entry itself is an "abstract class" we can very safely modify the name.
(The names are visible via `Object.prototype.toString.call(o)` or `Object.prototype.toString.call(o.__proto__.__proto__)`)
Overall, it sounds like there's no much desire pursue this. I'll revisit if we propose further effort in this area (e.g. building new functionality on these types).
Philip Jägenstedt
Aug 11, 2016, 6:14:55 AM8/11/16
to Joshua Bell, Addy Osmani, blink-dev
The concern was with Entry specifically. Do you still want to expose all of the other interfaces? And do you have any ideas for a new name for Entry?
Using [NoInterfaceObject] isn't without risk. I can't find it now, but there was some library on GitHub relating to directory upload or drag and drop that had to use UA sniffing because we had [NoInterfaceObject] on the interface where they could have done feature detection. It might even have been one of these, but I'm not sure.
smaug
Aug 11, 2016, 9:11:00 AM8/11/16
to Philip Jägenstedt, Joshua Bell, Addy Osmani, blink-dev
On 08/11/2016 01:14 PM, Philip Jägenstedt wrote:
> The concern was with Entry specifically. Do you still want to expose all of the other interfaces? And do you have any ideas for a new name for Entry?
>
> Using [NoInterfaceObject] isn't without risk. I can't find it now, but there was some library on GitHub relating to directory upload or drag and drop
> that had to use UA sniffing because we had [NoInterfaceObject] on the interface where they could have done feature detection. It might even have been
> one of these, but I'm not sure.
[NoInterfaceObject] here shouldn't cause need for UA sniffing, since in practice
> The concern was with Entry specifically. Do you still want to expose all of the other interfaces? And do you have any ideas for a new name for Entry?
>
> Using [NoInterfaceObject] isn't without risk. I can't find it now, but there was some library on GitHub relating to directory upload or drag and drop
> that had to use UA sniffing because we had [NoInterfaceObject] on the interface where they could have done feature detection. It might even have been
> one of these, but I'm not sure.
"webkitGetAsEntry" in DataTransferItem.prototype should be enough for detecting whether Entries are available.
>
> On Thu, Aug 11, 2016 at 1:38 AM 'Joshua Bell' via blink-dev <blin...@chromium.org <mailto:blin...@chromium.org>> wrote:
>
> I inquired with the folks behind window.fetch for how that was done. The response I got was along the lines of "we just hoped real hard".
>
> Since Entry itself is an "abstract class" we can very safely modify the name.
>
> (The names are visible via `Object.prototype.toString.call(o)` or `Object.prototype.toString.call(o.__proto__.__proto__)`)
>
> Overall, it sounds like there's no much desire pursue this. I'll revisit if we propose further effort in this area (e.g. building new
> functionality on these types).
>
>
> I would also strongly second the feedback from Elliot./Entry/ as a global name on window may well cause confusion in the current form. With
> respect to breakage, was research done on how much usage window.Entry has in the wild?
> /
> /On Wednesday, August 10, 2016 at 9:19:52 AM UTC-7, Joshua Bell wrote:
>
> This is a weird one...
>
>
> Contact emails
>
> jsb...@google.com <mailto:jsb...@google.com>
>
> This is a weird one...
>
>
> Contact emails
>
>
>
> 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.
>
>
> One particular oddness is present in the Chrome implementation: the types Entry, FileEntry, DirectoryEntry, and DOMFileSystem 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
>
> 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.
>
>
> One particular oddness is present in the Chrome implementation: the types Entry, FileEntry, DirectoryEntry, and DOMFileSystem are marked
> as [NoInterfaceObject]. That means you can't write code referring to the type (e.g. e instanceof FileEntry, FileEntry.prototype.xyz
> exposed on the global namespace.
>
>
> The intent is to drop [NoInterfaceObject] so the types can be referenced by name. Otherwise, there is no behavior change.
>
>
> 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 intent is to drop [NoInterfaceObject] so the types can be referenced by name. Otherwise, there is no behavior change.
>
>
> 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
>
>
>
> The risk is that adding these names to the global namespace breaks pages - e.g. relying on window.Entry *not* existing. It's basically
> impossible to find out without trying.
>
>
> /Interop:/
> The risk is that adding these names to the global namespace breaks pages - e.g. relying on window.Entry *not* existing. It's basically
> impossible to find out without trying.
>
>
>
> * Mozilla 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.
>
>
> If Chrome can successfully drop [NoInterfaceObject] here the other browsers will likely follow.
>
>
> OWP launch tracking bug
>
> TBD (will file if this gets approved)
>
>
> Entry on the feature dashboard <http://www.chromestatus.com/>
> * Mozilla 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.
>
>
> If Chrome can successfully drop [NoInterfaceObject] here the other browsers will likely follow.
>
>
> OWP launch tracking bug
>
> TBD (will file if this gets approved)
>
>
>
> TBD (will file if this gets approved)
>
>
>
> TBD (will file if this gets approved)
>
>
>
Philip Jägenstedt
Aug 11, 2016, 9:34:50 AM8/11/16
to smaug, Joshua Bell, Addy Osmani, blink-dev
On Thu, Aug 11, 2016 at 3:10 PM smaug <sm...@welho.com> wrote:
On 08/11/2016 01:14 PM, Philip Jägenstedt wrote:
> The concern was with Entry specifically. Do you still want to expose all of the other interfaces? And do you have any ideas for a new name for Entry?
>
> Using [NoInterfaceObject] isn't without risk. I can't find it now, but there was some library on GitHub relating to directory upload or drag and drop
> that had to use UA sniffing because we had [NoInterfaceObject] on the interface where they could have done feature detection. It might even have been
> one of these, but I'm not sure.
[NoInterfaceObject] here shouldn't cause need for UA sniffing, since in practice
"webkitGetAsEntry" in DataTransferItem.prototype should be enough for detecting whether Entries are available.
Ah, that was the interface! It used to have [NoInterfaceObject] in Blink and I found the problem I was thinking about:
Nevertheless, I think we shouldn't use [NoInterfaceObject] if renaming interfaces is still an option.
Philip
Domenic Denicola
Aug 11, 2016, 9:40:56 AM8/11/16
to Philip Jägenstedt, smaug, Joshua Bell, Addy Osmani, blink-dev
From: Philip Jägenstedt [mailto:foo...@chromium.org]
> Nevertheless, I think we shouldn't use [NoInterfaceObject] if renaming interfaces is still an option.
I agree. I've opened https://github.com/WICG/entries-api/issues/6 to propose a spec change. My hope would be that the spec gets changed with a rename and then this Intent to Ship can proceed with all of them at once.
> Nevertheless, I think we shouldn't use [NoInterfaceObject] if renaming interfaces is still an option.
Joshua Bell
Aug 11, 2016, 5:37:44 PM8/11/16
to Domenic Denicola, Philip Jägenstedt, smaug, Addy Osmani, blink-dev
Thanks, Domenic!
It looks like the bug discussion converged on renaming:
- DOMFileSystem → FileSystem
- Entry → FileSystemEntry
- FileEntry → FileSystemFileEntry
- DirectoryEntry → FileSystemDirectoryEntry
Pending further objections, the updated proposal is:
- Get Intent approval to make the change (since the risk is non-0 but believed extremely low)
- File a ChromeStatus entry
- Update the spec and notify other implementers
- Update Blink
(Last 3 are action items for me)
Elliott Sprehn
Aug 11, 2016, 5:53:59 PM8/11/16
to Joshua Bell, Domenic Denicola, Philip Jägenstedt, smaug, Addy Osmani, blink-dev
Sounds like a great plan!
Chris Harrelson
Aug 11, 2016, 6:31:14 PM8/11/16
to Elliott Sprehn, Joshua Bell, Domenic Denicola, Philip Jägenstedt, smaug, Addy Osmani, blink-dev
SGTM. Eagerly anticipating the new intent with the changed names. :)
--
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.
Reply all
Reply to author
Forward
0 new messages