jorendorff-streams-backlog.md

Changes in the standard that we need to adopt

• "3.8.3. new ReadableStreamDefaultController" and "3.10.3 new ReadableByteStreamController" should always throw a TypeError now. Controller setup is done in "3.9.11. SetUpReadableStreamDefaultController".

  Our CreateReadableByteStreamController() is also questionable.

• 3.8.4.2 has changed; ReadableStreamDefaultControllerCanCloseOrEnqueue needs to be compared against what we do

• "3.8.5.2 [[PullSteps]]" and "3.10.5.2 [[PullSteps]]" now take an argument forAuthorCode.

• "3.9.5 ReadableStreamDefaultControllerClose" should clear the private slots Likewise when a byte-stream becomes closed or errored, see 3.12.4.

• There is no PromiseInvokeOrNoop anymore.

• What is up with the step numbers in ReadableStream::updateDataAvailableFromSource?

Bugs

• We implement desiredSize getters in 3.8.4.1 and 3.10.4.2 with the same code, but they are non-generic algorithms; each is required to throw on the other type of this-value.

• need to file bugs for all failing streams wpt-tests

• an assertion using UnwrapReaderFromStreamNoThrow() is wrong since one side only of the double edge can be nuked

• I can't tell what the invariant is supposed to be for when ReadableStream::fixedSlots[Slot_Requests] can be undefined.

Style issues

• ReadableStreamControllerCallPullIfNeeded: in step 6 there's this code:

    Rooted<TeeState*> teeState(cx);
    teeState = &UncheckedUnwrap(&underlyingSource.toObject())->as<TeeState>();
  

  Not a bug! Immediate preceding if-condition checks that this is ok. But it should use unwrapAs.

• There are two places where we fire readableStreamWriteIntoReadRequestCallback. They should be common'd up.

Compartment-related issues

• Fix SetNewList, wat

• Is it a bug that ReadableStreamErrorInternal doesn't check that stream ==c e?

• ReadableStreamReaderGenericRelease contains some bodacious Maybe and wrap() hackery. If Compartment::wrap() actually requires cx->compartment() == this, it is necessary. Otherwise it is just super confusing.

  This has me kind of nervous because part 4 causes RSDR_releaseLock to call this method sometimes with cx->compartment() != reader->compartment().

• check RSDC_close callees for new situations where cx !=c controller.

• ditto RSDC_enqueue

• ditto RSDC_error (ReadableStreamControllerError looks dangerous!)

• ReadableStreamTee_Pull: when creating the handler for onFulfilled, are we crossing compartments? unwrappedTeeState is not same-compartment with cx?!?!

• When firing readableStreamWriteIntoReadRequestCallback (two places): // TODO: make this compartment-safe.

Things to test

• from chrome, call content fetch() and create a content reader (so that we exercise x-rays against this stuff)

• from chrome, call content fetch() and create a chrome reader (to see if it works, having that content-to-chrome edge internally)

Things to check on

• // TODO: add StructuredClone() intrinsic.

• When firing readableStreamWriteIntoReadRequestCallback (two places): // TODO: use bytesWritten to correctly update the request's state.