tracking bug: unprefix WebSockets

RESOLVED FIXED in Firefox 11

Status

()

Core
Networking: WebSockets
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: jduell, Assigned: jduell)

Tracking

({dev-doc-needed})

unspecified
mozilla11
dev-doc-needed
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox11+ fixed)

Details

(Whiteboard: [qa-])

Attachments

(1 attachment)

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

Updated

6 years ago
Depends on: 695636
(Assignee)

Updated

5 years ago
No longer depends on: 695636
(Assignee)

Comment 1

5 years ago
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.
Assignee: nobody → jduell.mcbugs
Status: NEW → ASSIGNED
Attachment #582621 - Flags: superreview?(bugs)
Attachment #582621 - Flags: review?(jonas)

Comment 2

5 years ago
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

5 years ago
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

5 years ago
Ah, you're doing that in bug 711205

Comment 5

5 years ago
(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

5 years ago
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+
(Assignee)

Comment 7

5 years ago
> 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
Attachment #582621 - Flags: review?(jonas) → review+
(Assignee)

Comment 8

5 years ago
https://hg.mozilla.org/mozilla-central/rev/2afd7ae68e8b
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla11
(Assignee)

Comment 9

5 years ago
s/MozWebsocket/WebSocket/g
Keywords: dev-doc-needed

Comment 10

5 years ago
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.
tracking-firefox11: --- → +
(Assignee)

Comment 11

5 years ago
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.

Updated

5 years ago
status-firefox11: --- → fixed
Whiteboard: [qa-]

Updated

5 years ago
Depends on: 743911
You need to log in before you can comment on or make changes to this bug.