695635 - tracking bug: unprefix WebSockets

Status: RESOLVED FIXED

(Core :: Networking: WebSockets, defect)

Description

[Jason Duell]

This is a meta-bug for tracking the work that needs to be done to unprefix websockets.

Comment 1

[Jason Duell]

Attachment: Unprefix websockets

s/MozWebSocket/WebSocket/g

Since this changes nsIMozWebSocket.idl, I assume I need both r/sr?  If not let me know.

Comment 2

[Mozilla RelEng Bot]

Try run for 4c3a36099f54 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=4c3a36099f54
Results (out of 107 total builds):
    success: 92
    warnings: 14
    failure: 1
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-4c3a36099f54

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Jason, any chance to remove or increase significantly the maxlimit for incoming messages before this?

IIRC, we've had bug reports for XHR because we can't handle larger than 2GB (max signed int32).
The current Websocket limit is tiny comparing to that.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Ah, you're doing that in bug 711205

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

(In reply to Mozilla RelEng Bot from comment #2)
> Try run for 4c3a36099f54 is complete.
> Detailed breakdown of the results available here:
>     https://tbpl.mozilla.org/?tree=Try&rev=4c3a36099f54
> Results (out of 107 total builds):
>     success: 92
>     warnings: 14
>     failure: 1
> Builds (or logs if builds failed) available at:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-
> 4c3a36099f54

Looks like there are some linux failures

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 582621 [details] [diff] [review]
Unprefix websockets


> [scriptable, uuid(f463b9b5-1408-4057-9224-e4f5bc33f17b)]
>-interface nsIMozWebSocket : nsISupports
>+interface nsIWebSocket : nsISupports
Could you please update uuid, just to be safe.

This patch shouldn't cause the linux failures, but looks like you
pushed also some other patches.

Comment 7

[Jason Duell]

> Could you please update uuid, just to be safe.

The uuid is updated in one of the underlying patches (which will land on tree at the same time).

I've verified that try is happy if I take out attachment 582496 [details] [diff] [review] from bug 666349 (fixes our response to broken servers that send mismatches subprotocol--I think we can live w/o it)

  https://tbpl.mozilla.org/?tree=Try&rev=a1208e55da09

Comment 8

[Jason Duell]

https://hg.mozilla.org/mozilla-central/rev/2afd7ae68e8b

Comment 9

[Jason Duell]

s/MozWebsocket/WebSocket/g

Comment 10

[LegNeato]

Is there any reason to not keep the prefix in as well? There were no incompatible changes between the last prefixed version and the final spec, right? I'm worried about breaking web content.

Comment 11

[Jason Duell]

Interesting point.  I don't know how many sites are relaying on MozWebSocket now in a way that would break w/o it.  Generally the advice on the web for writing portable Websockets code has been to do something like

  if(typeof(MozWebSocket) == "function") {
      this.socket = new MozWebSocket(applicationUrl);
    } else {
      this.socket = new WebSocket(applicationUrl);
  }

In which case things will go fine w/o us keeping the prefixed version too.  But we can of course support both if we thing it's needed.

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

We generally have not bothered with supporing both the prefixed and unprefixed version of an API. Most commonly we do see code similar to that in comment 11, though more like:

var ws;
if (WebSocket) {
  ws = new WebSocket(url);
}
else if (MozWebSocket) {
  ws = new MozWebSocket(url);
}
else {
  useXHRInstead();
}

Seems worth tracking, but beyond that I'm not sure that I'd worry about it.