Closed Bug 695635 Opened 13 years ago Closed 12 years ago

tracking bug: unprefix WebSockets

Categories

(Core :: Networking: WebSockets, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla11
Tracking Status
firefox11 + fixed

People

(Reporter: jduell.mcbugs, Assigned: jduell.mcbugs)

References

Details

(Keywords: dev-doc-needed, Whiteboard: [qa-])

Attachments

(1 file)

This is a meta-bug for tracking the work that needs to be done to unprefix websockets.
Depends on: 695636
No longer depends on: 695636
s/MozWebSocket/WebSocket/g

Since this changes nsIMozWebSocket.idl, I assume I need both r/sr?  If not let me know.
Assignee: nobody → jduell.mcbugs
Status: NEW → ASSIGNED
Attachment #582621 - Flags: superreview?(bugs)
Attachment #582621 - Flags: review?(jonas)
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
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.
Ah, you're doing that in bug 711205
(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 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.
Attachment #582621 - Flags: superreview?(bugs) → superreview+
> 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
https://hg.mozilla.org/mozilla-central/rev/2afd7ae68e8b
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla11
s/MozWebsocket/WebSocket/g
Keywords: dev-doc-needed
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.
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.
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.
Whiteboard: [qa-]
Depends on: 743911
You need to log in before you can comment on or make changes to this bug.