but FileError.code has been used at many places like DirectoryReaderSync.cpp and DomFileSystemSync.cpp etc. So removing FileError::code() needs to change other files too.
Good point, it's probably a bad idea to go from FileError to DOMError instead of to the final state, whatever that is. I've filed a spec bug for that: https://github.com/w3c/FileAPI/issues/11
Until that's sorted out, it's probably best to leave this alone, so I'm removing the Hotlist-GoodFirstBug label.
FileError.code is staying close to 0, which is good, since I just noticed:
FileError.NOT_FOUND_ERR; // 1
DOMException.NOT_FOUND_ERR; // 8
We just landed changing from DOMError to DOMException in Indexed DB. Maybe wait a cycle to see if that sticks, then drop FileError in favor of DOMException?
Request merge to M53 - just the commit in comment 11 (https://codereview.chromium.org/2023123002)
This announces the pending removal of the FileError interface in M54 (which I'll land if this merge is approved.
Confirmed in 54.0.2799.0 canary (64-bit) on Windows using this on the console.
f = new FileReader(); f.readAsArrayBuffer(new Blob()); f.abort(); f.onerror = e => console.log(f.error.code);
New deprecation message shows up as expected.
Approving merge to the commit in comment 11 (https://codereview.chromium.org/2023123002) to M53 branch 2785 based on comment #20. Please merge ASAP (if possible, before 5:00 PM PST today so it gets picked up for this week M53 Dev release). Thank you.
