1393769 - Consider to return a nsIAsyncInputStream in BlobImpl::CreateInputStream

Status: RESOLVED INVALID

(Core :: DOM: File, enhancement, P5)

Description

[Andrea Marchesini [:baku]]

Currently a BlobImpl returns a generic nsIInputStream. But doing this, FileReader and other APIs have to check if that stream is an nsIAsyncInputStream and in case it's not, they have to use nsITransport (or a pipe) and read off the current thread (often the main-thread).

Would be nice to return a nsIASyncInputStream always. Currently the only non-nsIAsyncInputStreams are FileBlobImpl objects. Maybe we can create a wrapper around those inputStreams and make them nsIAsyncInputStream as well.

Comment 1

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, untouched DOM/Storage bug's priority.

If you have reason to believe, this is wrong, please write a comment and ni :jstutte.

Comment 2

[Kagami Rosylight [:saschanaz] (they/them)]

(It's renamed years ago)

Comment 3

[Kagami Rosylight [:saschanaz] (they/them)]

Currently the only non-nsIAsyncInputStreams are FileBlobImpl objects.

This is not true since it currently returns SlicedInputStream which implements nsIAsyncInputStream: https://searchfox.org/mozilla-central/rev/4ef183d00fcd61e80399c14a2e5c7dff529ab388/dom/file/FileBlobImpl.cpp#265

That said, StringInputStream used by several BlobImpls is still non-nsIAsyncInputStream.

FileReader and other APIs have to check if that stream is an nsIAsyncInputStream and in case it's not, they have to use nsITransport (or a pipe) and read off the current thread (often the main-thread).

Bug 1371699 fixed this by introducing NonBlockingAsyncInputStream.

So this is not relevant anymore, closing.