Calling abort() on an inactive FileReader throws an exception

NEW
Unassigned

Status

()

Core
DOM
4 years ago
4 years ago

People

(Reporter: Arun Ranganathan, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
Current Behavior: 

var f = new FileReader();
f.abort();

will throw an exception, owing to bug 657964.

Expected Behavior:

The File API says: http://dev.w3.org/2006/webapi/FileAPI/#abort which is to do nothing about an abort() call when the status is EMPTY or DONE, NOT to throw an exception.

Other Browsers:

Chrome and Safari do not throw an exception.
Flags: needinfo?(khuey)
Is this a regression?
Somewhat: we purposefully changed to a behavior that does not match the spec.
(Reporter)

Comment 3

4 years ago
bz, I think that this behavior was introduced because the spec. itself was in flux.  I don't think it was a willful violation of spec.  If you think spec. behavior is wrong, I'd like to know of course :)
I vaguely recall that we intended to align with XHR or something here.  Maybe that never ended up happening.
Flags: needinfo?(khuey)

Comment 5

4 years ago
XMLHttpRequest's abort() never throws. I think generally we should throwing unless it catches something that's an actual mistake or cannot be readily handled. I don't think that's the case here.

Comment 6

4 years ago
Created attachment 826457 [details] [diff] [review]
FileReaderException.diff
Attachment #826457 - Flags: review?(bugs)

Comment 7

4 years ago
Hey guys,
Should I also remove [Throws] just before void abort(); in FileReader.webid?
Thanks
Comment on attachment 826457 [details] [diff] [review]
FileReaderException.diff

Yes, you should remove [Throws] and the ErrorResult param since per spec
the method doesn't throw.
Attachment #826457 - Flags: review?(bugs)
You need to log in before you can comment on or make changes to this bug.