Closed Bug 1482250 Opened 6 years ago Closed 6 years ago

Mid "0" is a foot-gun (caused some JS library breakage).

Categories

(Core :: WebRTC: Signaling, defect, P2)

61 Branch
defect

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox61 --- unaffected
firefox62 --- unaffected
firefox63 + wontfix

People

(Reporter: jib, Assigned: bwc)

References

Details

(Keywords: regression, site-compat)

Attachments

(1 file)

Bug 1476600 changed mid from e.g. "sdparta_0" to "0", for decent reasons (Bug 1476600 comment 15). Chrome also uses it AFAIK.

Unfortunately, "0" is falsy in JavaScript, causing compatibility grief with some libraries, since

    if (transceiver.mid) {
      // we have mid!
    }

would do nothing for "0" or null.

Since mid is nullable in the spec, should we save ourselves some grief and avoid "0", e.g. start counting from "1"?

I'm flagging this as a regression since it caused some breakage.

[1] http://w3c.github.io/webrtc-pc/#idl-def-rtcrtptransceiver
[Tracking Requested - why for this release]: regression, in the sense that new behavior breaks some JS libraries.
Rank: 17
Well, I'd say this behavior in JS is the foot-gun, but making this change is probably a good idea.
Before changing the behaviour again : doesn't Chrome in "Unified Plan" mode also use "0" for the first mid? If so I'd say we are giving libraries a useful heads up that their code is brittle..
I've pinged Chrome folks, lets see if they can turn that into an issue themselves. I much prefer the service here :-)
Comment on attachment 8999186 [details]
Bug 1482250: Start mid strings at 1 instead of 0 because of JS bool conversions. r?jib

Jan-Ivar Bruaroey [:jib] (needinfo? me) has approved the revision.
Attachment #8999186 - Flags: review+
First of all it would be pretty sad to have JavaScript rule the content of network protocols.

I'm certainly not a JavaScript expert, but according to my limited testing:

  var foo = "1"

is True in JavaScript and

  var foo = "0"

is also True.

So I don't think we should ship this.
Relevant explanation https://stackoverflow.com/questions/7615214/in-javascript-why-is-0-equal-to-false-but-when-tested-by-if-it-is-not-fals

So to me this was a bug in on JavaScript SDP library, and it is fixed on their end already.
So do we land this as it is or close it out?
Flags: needinfo?(drno)
I think we should close it and not land it.

But I would be interested if Byron or jib have different thoughts.
Flags: needinfo?(jib)
Flags: needinfo?(drno)
Flags: needinfo?(docfaraday)
I can see an argument for either way, and have no strong opinion.
Flags: needinfo?(docfaraday)
Keywords: site-compat
(In reply to Nils Ohlmeier [:drno] from comment #9)
>   var foo = "0"
> 
> is also True.

Ah, right. As your SO link points out, it's only when comparing against numbers it goes pear shaped, e.g.

    "0" == false

is true. So presumably then the JS library in question was storing mids as numbers? Iñaki is that right?

Unless we have reason to believe this is common, I agree we can drop this fix.
Flags: needinfo?(jib) → needinfo?(ibc)
https://github.com/w3c/ortc/pull/864 -- note that ORTC is moving away from numeric rids in examples.
Hi guys, the problem here is not so much JavaScript itself and its lazy `==` comparisons, but the usage of the JavaScript sdptransform library:

https://github.com/clux/sdp-transform

Unfortunately, when that library parses a SDP string, every field that could be expressed as number is converted from string to number. This is, if `a=mid:0`, initially the parser will get "0" string, but will later convert it into 0 (number).

I felt the pain in mediasoup: https://github.com/versatica/mediasoup/issues/213
Flags: needinfo?(ibc)
Given that Chrome with RTCPeerConnection({sdpSemantics: 'unified-plan'}) also uses 'a=mid:0' I don't think we should fix it.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: