Closed Bug 1641825 Opened 4 years ago Closed 4 years ago

nsBufferedInputStream should call the callback immediately upon receiving AsyncWait if stream is closed

Categories

(Core :: Networking, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla79
Tracking Status
firefox79 --- fixed

People

(Reporter: ssengupta, Assigned: ssengupta)

References

Details

(Whiteboard: [necko-triaged])

Attachments

(2 files)

Currently multiple implementations of nsIAsyncInputStream return an error code (e.g., NS_BASE_STREAM_CLOSED) and do not call the callback if AsyncWait is called and the stream is already closed, which is not expected behaviour. These implementations should be updated to call the callback immediately in such a situation instead of returning an error.

Blocks: 1619953
Attachment #9152688 - Attachment description: Bug 1641825 - nsBufferedInputStream does not return error and executes callback on AsyncWait/AsyncLengthWait if stream is closed r=baku → Bug 1641825 - P1 - nsBufferedInputStream does not return error and executes callback on AsyncWait/AsyncLengthWait if stream is closed r=baku
Whiteboard: [necko-triaged]
Pushed by cbrindusan@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e7bdd6c7c3d4
P1 - nsBufferedInputStream does not return error and executes callback on AsyncWait/AsyncLengthWait if stream is closed r=baku,necko-reviewers,mayhemer
https://hg.mozilla.org/integration/autoland/rev/1653291bd1b5
P2 - GTest cases added for nsBufferedInputStream to test AsyncWait/AsyncLengthWait behaviour when stream closed r=baku,necko-reviewers,mayhemer
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla79
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: