Created attachment 737339 [details] Test Case STR: 1. Load the attached test case 2. Go into the web console and type localDC.stream Expected: Don't know the exact behavior expected here. Actual: I wouldn't expect to get the maximum possible value for an unsigned short - 65535. That number feels...strange to use? After establishing the handshake, I see 0 and 1 being used. Can we come up with a better numbering scheme here that makes sense?
The proposal for the API here says that channel.stream is not valid until onopen fires. (Internally, 65535 is used as an invalid value to flag that the stream isn't assigned yet.)
We could return something non-numeric if the state isn't 'open'... if so we should add that to the spec proposal.
Assignee: nobody → rjesup
Priority: -- → P3
(In reply to Randell Jesup [:jesup] from comment #2) > We could return something non-numeric if the state isn't 'open'... if so we > should add that to the spec proposal. Hmm..okay. 65535 felt odd to use to indicate "invalid" from my sense. Why not use -1?
Because internally it's a unsigned short, as we're just exposing it via .stream (and it's an unsigned short in the IDL, so we can't return -1 or undefined even if we want to)
backlog: --- → webRTC+
Whiteboard: [webrtc][blocking-webrtc-][spec-issue][webrtc-uplift] → [spec-issue][webrtc-uplift]
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
Sorry for digging this up. :) Expected value is 'null' before assignment.
You need to log in before you can comment on or make changes to this bug.