Closed Bug 1577830 Opened 6 years ago Closed 5 months ago

RTCDataChannel.send order is wrong for blobs

Categories

(Core :: WebRTC, defect, P2)

defect

Tracking

()

RESOLVED FIXED
147 Branch
Tracking Status
firefox147 --- fixed

People

(Reporter: jib, Assigned: bwc)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Firefox does not preserve datachannel.send() call order when Blobs are sent (relative to other data sent).

STRs: https://jsfiddle.net/jib1/v2ctmg5L/ and web-platform-tests/wpt#18770.

For details see w3c/webrtc-pc#2215.

The order is preserved when both data1 and data2 are Blobs https://plnkr.co/edit/7oYM0i?p=preview

Marking as P2. :jib, please change if you disagree.

Priority: -- → P2

This seems to be because we're doing a couple of extra dispatches when sending a Blob. These extra dispatches seem to be related to a performance optimization that offloads the reading of a Blob to another thread:

https://searchfox.org/mozilla-central/rev/f1e99da78fe6c3c68696358dac06aed90f8112d3/netwerk/sctp/datachannel/DataChannel.cpp#2765

We definitely should be waiting until after the blob is sent before sending other data.

There's a test-case in webrtc/RTCDataChannel-send-blob-order.html that fails because of this bug, but now this test-case intermittently "succeeds" on fission for some reason.

Severity: normal → S3

FWIW https://jsfiddle.net/jib1/e0z61uo2/ shows WebSocket does not have this problem.

But until Chromium adds blob support (webrtc 2276) this is probably low priority.

Priority: P2 → P3

Bumping back to P2 due to recent activity in other browsers.

Priority: P3 → P2
Priority: P2 → P3
No longer blocks: webrtc-triage
Priority: P3 → P2
Assignee: nobody → docfaraday
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → 147 Branch
QA Whiteboard: [qa-triage-done-c148/b147]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: