1959527 - Replace nsIInputStream::isNonBlocking with a streamFlags attribute that provides a bitmask of flags providing STREAM_NONBLOCKING and STREAM_BUFFERED and implement a backwards-compatibility helper

Status: ASSIGNED

(Core :: XPCOM, enhancement)

Description

[Andrew Sutherland [:asuth] (he/him)]

In a discussion in the #XPCOM channel on matrix starting on March 5th, 2025 discussing the side-effects of NS_InputStreamIsBuffered and how to avoid having the method potentially perform reads for side-effect, potentially resulting in blocking I/O on threads that aren't expecting it, Nika proposed the following strategy:

I think I'd probably replace isNonBlocking() with a new method like:

cenum Flags : uint8_t {
 STREAM_NONBLOCKING = 0x1,
 STREAM_BUFFERED = 0x2,
};

readonly attribute Flags streamFlags;

And perhaps re-add a GetIsNonBlocking() method which can be called from existing callers for transition with %{C++ or something
That way if/when we discover we need more flags on streams in the future, a new method doesn't need to be added to every single nsIINputStream implementation in the browser.

And:

If you do that, perhaps also remove the nsIBufferedInputStream implementation from nsPipeInputStream given that it won't be necessary

Related bugs:

• Bug 1953349 tracks wanting to more consistently serialize the state of streams so that if they were perturbed due to a call like this and then serialized, their state will be consistent. (More details in that bug)
• Bug 1255070 wanted to make more streams implement nsIBufferedInputStream to accomplish a similar goal as a follow-up to bug 1093357 having made nsPipeInputStream and nsIBufferedInputStream; with this bug implemented, that bug can likely be marked WONTFIX
• Bug 1255604 about having NS_InputStreamIsBuffered and its output variant revise their response to NS_BASE_STREAM_WOULD_BLOCK should also be mooted if we are just depending on the flag and stop calling the streams to figure out if they are buffered.