Intent to Remove: FileError interface
Joshua Bell
Note: we deprecated FileError in 2013 prior to the "Intent" process, so there's no "Intent to Deprecate" to link to.
Primary eng (and PM) emails
jsb...@chromium.org, foo...@chromium.org
Summary
Remove FileError interface, return DOMException instead.
Motivation
FileError was removed from File API (https://w3c.github.io/FileAPI/) after Chrome had shipped the functionality. Other browsers do not use it, returning a DOMError instead.
This surfaces on:
- FileReader.error - specified as DOMError now
- FileWriter.error - chrome-specific sandboxed File System API, no active spec
- passed to the ErrorCallback from some FileSystem API async operations
- thrown from FileSystem API sync operations
https://codereview.chromium.org/22831019
Microsoft plans to ship additional file/directory upload APIs compatible with Chrome and (per alia@) does not plan to use FileError here, so we'd like to tidy up this corner of the platform.
Compatibility Risk
Per MDN (https://developer.mozilla.org/en-US/docs/Web/API/FileError) this has never been supported in IE/Edge or Safari, and was unshipped successfully in Firefox 13. Instead, DOMError is used.
Note that DOMError is also slated for removal from the platform, in favor of just using DOMException. We successfully moved Indexed DB from using DOMError to DOMException last year (https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/XAlBg66UB7c/G4GNCFLnwCQJ), so we believe that is safe. Chrome APIs that today return FileError would start returning the corresponding DOMException instead.
Alternately, we could switch from FileError to DOMError and later move to DOMException, but given our experience with IndexedDB we believe that would be unnecessary churn. This is the last remaining use of DOMError in the platform.
Alternative implementation suggestion for web developers
This would only impact code that relies on comparing the error instance's code (e.g. `e.code`) directly against FileError enum values (FileError.NOT_FOUND_ERR, etc), which only exist in Chrome. Code that tests against hardcoded constants (e.g. `e.code === 1` could fail, e.g. report incorrect errors to the user - but this code would not have worked in other browsers since `code` is not present on DOMError.Developers should instead rely on `e.name` - this works across FileError, DOMError, and DOMException which share names. Any code receiving one of these objects can inspect `name` and `message`.
Usage information from UseCounter
Usage of FileError's `code` attribute dropped to almost nothing in April 2015:
https://www.chromestatus.com/metrics/feature/timeline/popularity/126
HTTP Archive shows only 13 hits for "FileError.*_ERR": some from Cordova/PhoneGap shims, others from Chrome's File System API (which will be affected by this change), and none from uses of the standardized File API. Unfortunately we can't easily search for uses of `.code`, and must rely on the use counter.
OWP launch tracking bug
Entry on the feature dashboard
Will create one if this is approved. (Keep me honest here, jmedley@!)Requesting approval to remove too?
Yes. Proposing to remove in M53.
Rick Byers
Philip Jägenstedt
Chris Harrelson
--
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.