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
  

It has been deprecated since August 2013, with `code` - the only unique property - logging a deprecation warning ("FileError is deprecated. Please use the 'name' or 'message' attributes of DOMError rather than 'code'.")

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

https://crbug.com/496901

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‏]

LGTM1

Checked the internal use counter data - 0.0001%.  I agree the risk should be very low, thanks for the extra httparchive search anyway!

[Philip Jägenstedt‏]

LGTM2

M52 is estimated to reach stable on July 26, what do you think about adding a date to the deprecation message and having that merged? Given the usage it might not cause a single developer to act, but it's hard to say, and this message has been emitted for so long that some might think it's just noise to be ignored.

[Chris Harrelson‏]

LGTM3

--
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.