Last Comment Bug 695635 - tracking bug: unprefix WebSockets
: tracking bug: unprefix WebSockets
Status: RESOLVED FIXED
[qa-]
: dev-doc-needed
Product: Core
Classification: Components
Component: Networking: WebSockets (show other bugs)
: unspecified
: All All
: -- normal (vote)
: mozilla11
Assigned To: Jason Duell [:jduell] (needinfo me)
:
Mentors:
Depends on: 743911 664284 666349 676439 695250
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-19 02:26 PDT by Jason Duell [:jduell] (needinfo me)
Modified: 2012-04-09 21:25 PDT (History)
16 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
fixed


Attachments
Unprefix websockets (34.57 KB, patch)
2011-12-17 19:16 PST, Jason Duell [:jduell] (needinfo me)
jonas: review+
bugs: superreview+
Details | Diff | Splinter Review

Description Jason Duell [:jduell] (needinfo me) 2011-10-19 02:26:32 PDT
This is a meta-bug for tracking the work that needs to be done to unprefix websockets.
Comment 1 Jason Duell [:jduell] (needinfo me) 2011-12-17 19:16:43 PST
Created attachment 582621 [details] [diff] [review]
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 2011-12-17 22:50:35 PST
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/jduell@mozilla.com-4c3a36099f54
Comment 3 Olli Pettay [:smaug] 2011-12-18 05:03:32 PST
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] 2011-12-18 05:04:16 PST
Ah, you're doing that in bug 711205
Comment 5 Olli Pettay [:smaug] 2011-12-18 06:51:42 PST
(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/jduell@mozilla.com-
> 4c3a36099f54

Looks like there are some linux failures
Comment 6 Olli Pettay [:smaug] 2011-12-18 07:02:06 PST
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 [:jduell] (needinfo me) 2011-12-18 11:26:31 PST
> 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 [:jduell] (needinfo me) 2011-12-20 03:33:48 PST
https://hg.mozilla.org/mozilla-central/rev/2afd7ae68e8b
Comment 9 Jason Duell [:jduell] (needinfo me) 2011-12-20 03:38:16 PST
s/MozWebsocket/WebSocket/g
Comment 10 christian 2011-12-20 07:30:56 PST
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 [:jduell] (needinfo me) 2011-12-21 23:35:23 PST
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) PTO Until July 5th 2011-12-22 11:48:16 PST
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.

Note You need to log in before you can comment on or make changes to this bug.