DCHECK(options);Should this be a `CHECK`? Same in other places.
// strong hold during the async gap. nullptr is safe — Persistent<T>```suggestion
// strong reference during the async gap. nullptr is safe — Persistent<T>
```
// strong hold during the async gap. nullptr is safe — Persistent<T>What does this mean? Can you update the comment to clarify? Same in other places.
send_stream->setSendOrder(send_order);If `setSendGroup` was to throw, should we check for that before `setSendOrder`? Same for the bidirectional code.
if (!try_catch.HasCaught()) {
if (send_group) {
send_stream->setSendGroup(send_group, PassThroughException(isolate));
}
send_stream->setSendOrder(send_order);
}Since this is the same for both unidirectional and bidirectional streams, can we factor this out into a helper function on `WebTransportSendStream`? Maybe `ApplySendOptions()`?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Should this be a `CHECK`? Same in other places.
Done. Changed to `CHECK(options)` in all three places: ` createUnidirectionalStream()`, `createBidirectionalStream()`, and `ExtractSendStreamOptions()`.
// strong hold during the async gap. nullptr is safe — Persistent<T>```suggestion
// strong reference during the async gap. nullptr is safe — Persistent<T>
```
Addressed together with Comment 2, rewrote the entire comment block for clarity.
// strong hold during the async gap. nullptr is safe — Persistent<T>What does this mean? Can you update the comment to clarify? Same in other places.
Done. Rewrote the comment to be explicit about what's happening:
> Capture send_group via WrapPersistent so it survives the asynchronous
Mojo round-trip (between `CreateStream()` and the callback). The
transport's ` send_groups_` registry uses `WeakMember`, so without this
strong reference the group could be garbage-collected if JS drops all
references before the callback fires. `nullptr` is safe, `Persistent<T>`
accepts null.
If `setSendGroup` was to throw, should we check for that before `setSendOrder`? Same for the bidirectional code.
Fixed `ApplySendStreamOptions()` now calls `setSendGroup()` first, checks `exception_state.HadException()`, and returns early before calling `setSendOrder()` if it threw. Applied to both unidirectional and bidirectional paths
if (!try_catch.HasCaught()) {
if (send_group) {
send_stream->setSendGroup(send_group, PassThroughException(isolate));
}
send_stream->setSendOrder(send_order);
}Since this is the same for both unidirectional and bidirectional streams, can we factor this out into a helper function on `WebTransportSendStream`? Maybe `ApplySendOptions()`?
Done. Added `WebTransportSendStream::ApplySendStreamOptions(send_group, send_order, exception_state)` that handles the sequencing correctly (setSendGroup → check exception → setSendOrder). Both `OnCreateSendStreamResponse` and `OnCreateBidirectionalStreamResponse` now use this single helper.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
lgtm, let me add @ri...@chromium.org as a third_party/blink/renderer/modules/webtransport/ owner
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
lgtm with nits
bool ExtractSendStreamOptions(WebTransportSendStreamOptions* options,The style guide generally discourages out-params: see https://google.github.io/styleguide/cppguide.html#Inputs_and_Outputs
I suggest defining a nested class and returning an optional value, something like
```
struct SendStreamOptions {
STACK_ALLOCATED();
public:
WebTransportSendGroup* send_group = nullptr;
int64_t send_order = 0;
};
std::optional<SendStreamOptions> ExtractSendStreamOptions(
const WebTransportSendStreamOptions*,
ExceptionState&);
```
// Regression: sendOrder=0 must not be silently dropped (was a previous bugI don't understand this comment. This test has exactly the same expectations as CreateUnidirectionalStreamWithEmptyOptions, below, so would behave the same whether the
```
options->setSendOrder(0);
```
line was there or not. Or is the purpose of the test to prove that calling that changes nothing?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
bool ExtractSendStreamOptions(WebTransportSendStreamOptions* options,The style guide generally discourages out-params: see https://google.github.io/styleguide/cppguide.html#Inputs_and_Outputs
I suggest defining a nested class and returning an optional value, something like
```
struct SendStreamOptions {
STACK_ALLOCATED();
public:
WebTransportSendGroup* send_group = nullptr;
int64_t send_order = 0;
};
std::optional<SendStreamOptions> ExtractSendStreamOptions(
const WebTransportSendStreamOptions*,
ExceptionState&);
```
Done. Refactored to return `std::optional<SendStreamOptions>` as suggested. Defined a `STACK_ALLOCATED()` nested struct with `send_group` and `send_order` fields, and updated both call sites to use the returned value
// Regression: sendOrder=0 must not be silently dropped (was a previous bugI don't understand this comment. This test has exactly the same expectations as CreateUnidirectionalStreamWithEmptyOptions, below, so would behave the same whether the
```
options->setSendOrder(0);
```
line was there or not. Or is the purpose of the test to prove that calling that changes nothing?
You're right, in the current implementation `sendOrder` defaults to 0 in the IDL, so this test is indistinguishable from `CreateUnidirectionalStreamWithEmptyOptions`. The comment references a bug from a previous CL where there was an `if (send_order != 0)` guard that would skip the explicit zero, but that guard no longer exists. Removed the test.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +2 |
[Webtransport]Accept options in UnidirectionalStream/BidirectionalStream
Add WebTransportSendStreamOptions (inheriting WebTransportSendOptions)
so that createUnidirectionalStream() and createBidirectionalStream() can
accept sendGroup and sendOrder at stream creation time, per the W3C
WebTransport spec.
This CL:
- Adds WebTransportSendOptions and WebTransportSendStreamOptions IDL
dictionaries. Both sendGroup and sendOrder members are gated behind
RuntimeEnabled=WebTransportSendGroup.
- Updates createUnidirectionalStream() and createBidirectionalStream()
IDL signatures to accept optional WebTransportSendStreamOptions.
- Adds ExtractSendStreamOptions() helper to validate options (rejects
cross-transport sendGroup) and wire them through the async Mojo
callback to the newly created stream.
- Captures sendGroup via WrapPersistent in the BindOnce callback to
ensure the group survives the async gap; the transport's registry
uses WeakMember so unreferenced groups can be collected.
- Applies sendGroup/sendOrder inside the v8::TryCatch scope so any
exception from setSendGroup() properly rejects the promise.
- Adds 10 new unit tests covering: sendGroup+sendOrder at creation,
sendOrder-only, sendOrder=0, empty options, explicit null group,
cross-transport rejection (uni + bidi), and flag-off behavior.
Setters are local-only stubs — Mojo plumbing for network-side initial
priority will be added in a follow-up CL.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |