659324 - prefix the JS API for WebSockets

Status: RESOLVED FIXED

(Core :: Networking: WebSockets, defect)

Description

[Asa Dotzler [:asa]]

from bug 640003 comment 74 by Jonas: 

We really *really* should prefix the JS API here. There are a lot of questions that the API spec editor still hasn't responded to, some of which would change the API in pretty big ways.

Comment 1

[Christopher Blizzard (:blizzard)]

Jonas, this is news to me.  Can you say what the changes we're likely to see?  I was under the impression that the API was relatively stable.  If there's an issue here it's too late for Firefox 6 - we'll have to disable WebSockets.  Again.

Comment 2

[Paul Rouget [:paul]]

(In reply to comment #1)
> Jonas, this is news to me.  Can you say what the changes we're likely to
> see?  I was under the impression that the API was relatively stable.  If
> there's an issue here it's too late for Firefox 6 - we'll have to disable
> WebSockets.  Again.

See https://bugzilla.mozilla.org/show_bug.cgi?id=640003#c77

Comment 3

[Christopher Blizzard (:blizzard)]

OK.  Talked with Jonas.  There are still some concerns that are worth addressing.  So the current plan is:

1. Ship websockets with Firefox 6, with the -07 protocol but with a prefixed API.  This will let us get some testing in the wild, both on the Aurora and Beta channels, but also in production.

2. The timeline for any API changes will happen before the Aurora cut for Firefox 7, six weeks from now.  Jonas will drive this in the upstream W3C bug:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12102

Comment 4

[Christopher Blizzard (:blizzard)]

So who is gonna do it?

Comment 5

[Fredrik Larsson (:nossralf)]

Attachment: Add Moz prefix to WebSocket constructor

I'm not sure if this is what you had in mind, but I figured I'd have a try at it. Should CloseEvent be prefixed as well?

Comment 6

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

Comment on attachment 535958 [details] [diff] [review]
Add Moz prefix to WebSocket constructor

Yay! This is great!

I don't think we need to worry about prefixing CloseEvent. It's much less likely to change, but more importantly, it's much much less likely that people will come to depend on it's behavior in such a way that we can't modify it if we have to.

Comment 7

[Joel Martin]

The changes that Ian (the editor) applied to the draft spec don't actually end up changing the API in a breaking manner (from what I can tell): http://www.whatwg.org/specs/web-apps/current-work/complete/network.html#network. The binaryType attribute is new but has a logical default (and only applies if the server sends a binary message anyways). The .open() proposal was not applied and the initialization process is still the same as before. The send() method now accepts binary types in addition to strings as before.

Also, the current API bug where the discussion has happened has been resolved: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12102

Might still be a good idea to prefix until things are more certain but I thought I would point out that it seems likely that the API is going to stay backwards compatible with what already exists in the wild.

Comment 8

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

Yeah. Microsoft is still pushing for the .open syntax so I don't think there's a full resolution there.

I'm also chatting with Hixie about how to handle binary types, but I agree that that is likely to be additive and fully backwards compatible.

Comment 9

[Johnny Stenback (:jst)]

Tracking for 6. This patch looks ready to land, and once it's landed it needs an approval request to land in aurora.

Comment 10

[Christopher Blizzard (:blizzard)]

Once Jonas is comfortable, we'll unprefix.  We can even do that in the Aurora cycle if it's short.

Comment 11

[Fredrik Larsson (:nossralf)]

Attachment: Att Moz prefix to WebSocket constructor, on mozilla-central this time

I based the previous patch on the aurora branch, which I think was a mistake. These are the same changes on mozilla-central instead.

I guess I don't need to mark this checkin-needed, or is that a good thing to do generally?

Comment 12

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

What were the differences between aurora and mozilla-central?

I'm fine with not doing any prefixing on m-c and just doing aurora, in which case we should just use your first patch, right?

Comment 13

[Fredrik Larsson (:nossralf)]

(In reply to comment #12)
> What were the differences between aurora and mozilla-central?

There were some slight differences in the offsets in the patch files, that's all. Maybe hg qimport or patch would have solved those automatically, and the new patch was redundant, I don't know. I just wanted to make landing problem free, as comment 9 made it sound like mozilla-central was the primary target. (It's possible I'm over-cautious here.)
 
> I'm fine with not doing any prefixing on m-c and just doing aurora, in which
> case we should just use your first patch, right?

Yup.

Comment 14

[Christopher Blizzard (:blizzard)]

Ping.  This hasn't landed yet, right?

Comment 15

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

Comment on attachment 535958 [details] [diff] [review]
Add Moz prefix to WebSocket constructor

We'd like to take this patch in order to guard ourselves against future spec changes.

It's just renaming a new API so it should be very low risk and comes with tests.

Comment 16

[Josh Aas]

I ran this on try today. Run hasn't entirely completed but it is close and all green.

Comment 17

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

Crap, i forgot to mark this FIXED. I checked it in as soon as we got the approval

https://hg.mozilla.org/releases/mozilla-aurora/rev/0b22e6569813

Comment 18

[Josh Aas]

Jonas - shouldn't this be on trunk as well?

Comment 19

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

I think our plan was to not prefix trunk in an effort to make FF7 be the release target for an unprefixed websockets implementation.

I'm happy to keep it prefixed a bit longer though, but my impression is that others are not. I'm ok with aiming for making FF7 unprefixed.

Comment 20

[Boris Zbarsky [:bzbarsky]]

Sounds like this needs a tracking-ff7 to evaluate whether this needs to be prefixed in 7 as well when we getthere.

Comment 21

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

I would rather have it prefixed in Nightly until we get closer to un-prefixing it. Otherwise, Nightly users will have trouble visiting WebSockets demos that are designed to work with FF6 Aurora/Beta/Final.

Comment 22

[Daniel Veditz [:dveditz]]

Jonas, are you going to check this into mozilla-central too? See comment 21

Comment 23

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

We should do this for mozilla-central too. There are some things we still need to do before websockets is completely ready. For example, we need to make sure it works with HSTS and CSP, and we need to improve some things about the way WebSockets over TLS works. Let's check this into mozilla-central and file a new bug for un-prefixing it, so that we can set  the bug dependencies correctly.

Comment 24

[Boris Zbarsky [:bzbarsky]]

Requesting tracking for 8 too, so we can figure out what the prefixing story is.

Comment 25

[Christopher Blizzard (:blizzard)]

Can you guys just change this on m-c until we're ready to unprefix?

Comment 26

[Dão Gottwald [:dao]]

The patch applies neither on mozilla-central nor on aurora and needs approval for current aurora.

Comment 27

[Patrick McManus [:mcmanus]]

Attachment: udpated-ws-prefix 1

Comment 28

[Patrick McManus [:mcmanus]]

still waiting for the binary API to settle down - so the prefix will stay in order. I've updated this patch.

It is my intention to merge it to both ff7(aurora) (pending a+.. it previously got an aurora approval - but that was for ff6 so I'll ask again) and ff8(nightly).

I personally would rather it not be on nightly, but I seem to be outvoted. And this way I don't need to seek a? again when ff8 gets promoted if we still haven't figured out the binary issues :)

The newly rolled patch is a combination of 659324-that-is-on-beta, its followon patch 664692-that-is-on-beta, and a little fixup for 664860 which renamed things. No new code.

Comment 29

[Joel Martin]

Is there an implementation of the binary API. I searched and wasn't able to find a relevant bug.

The binary API appears fairly "quiet" to me. The W3C bug (http://www.w3.org/Bugs/Public/show_bug.cgi?id=12102) has been quiet since 5-27 when it was added to the WHATWG spec and marked "fixed resolved". I don't see any W3C bugs or discussion since then to indicate that any substantial changes are likely to the current binary API definition.

The section of the WHATWG spec (http://www.whatwg.org/specs/web-apps/current-work/complete/network.html#network) is marked "ready for first implementations".

If we have an alpha build with the binary API implemented, I would like to test it out.

Comment 30

[Patrick McManus [:mcmanus]]

(In reply to comment #29)
> Is there an implementation of the binary API.

I am not aware of one.

Comment 31

[Joel Martin]

I should have stated the actual question I was asking: What are we waiting on?

As I noted, the binary API doesn't appear to be in flux since it was resolved two months ago (as a plus it's backwards compatible with the string/UTF-8 only definition currently implemented). The WHATWG is wanting implementer feedback. There is an available and willing tester (i.e. me). Lets get a jump on the competition. Go, go, go! Pew, pew, pew! :-)

Comment 32

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/137316b6e618

Comment 33

[LegNeato]

Comment on attachment 548261 [details] [diff] [review]
udpated-ws-prefix 1

Approved for releases/mozilla-aurora. Please land asap

Comment 34

[Patrick McManus [:mcmanus]]

http://hg.mozilla.org/releases/mozilla-aurora/rev/9a08685d1424

Comment 35

[Joel Martin]

WebSockets HyBi-10 has been announced in Chrome 14: http://blog.chromium.org/2011/08/new-websocket-protocol-secure-and.html . It is not prefixed.

In light of that, and the fact that the new W3C/WHATWG API definition is backwards compatible (and is unlikely to change in an incompatible way), it may not make sense to prefix the WebSocket constructor any longer. Just a thought.

Comment 36

[Boris Zbarsky [:bzbarsky]]

We should talk to the chrome folks about the "not prefixed" bit, since the API spec is completely unstable so far!  I'll send some mail.

Comment 37

[Boris Zbarsky [:bzbarsky]]

http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0565.html

Comment 38

[Boris Zbarsky [:bzbarsky]]

Oh, and to be clear, Chrome is aiming to ship websocket in about 3 months if it's just landed it on the dev channel.  That about corresponds to Firefox 8 or Firefox 9.  Maybe the spec will be stable by then.  This bug was about Firefox 6.

I also don't know why you think that the API definition is stable.  It's not.  That is, the way the function calls look won't change, but what they do on the protocol level is most likely to change radically; see the webapps threads about compression being required (as now) vs forbidden (what it's likely to end up as).

Comment 39

[Boris Zbarsky [:bzbarsky]]

That said, I do think we should file a bug, targeted probably for Fx9, to unprefix the JS API.

Comment 40

[Joel Martin]

Good luck (genuinely) in trying to convince Chrome to prefix. It has been unprefixed and enabled since Chrome 5 so I think they are unlikely to "break" it after two years. If you can convince them, then I'm slightly in favor of prefixing. Otherwise, I'm moderately in favor of not prefixing it in Firefox.

Also, I'm not arguing that the API or the protocol are _stable_; that has a specific meaning in the context of standards. I'm saying that the API is unlikely to change in a backwards incompatible way anytime in the near future. Even Microsoft participated in and hasn't objected to the WebSocket API as currently defined by the W3C.

And in regards to the protocol, I think it is a large exaggeration to say that it is "likely to change radically". I'm a participant in HyBi (and to a lesser degree in the W3C/WHATWG discussion). The current draft spec has completed internal last call. It was proposed to the IESG to be published on Jul 11th. 

Regarding deflate-stream, the discussion was heated, but it was heated because the version proposed to the IESG was vague about whether it was mandatory or optional. The consensus is that at best it should be optional, the discussion was over whether it should be even be in the spec as an option. Last week the chairs officially removed it from the spec.

The HyBi discussion for the last several months (always heated, but that seems to be the nature of WGs) has been about the text of the standard or about ancillary issues (DNS SRV, extension handling, etc) not about the core protocol. There is very little chance of radical changes to the current protocol prior to publishing by the IETF. The main risk is of a security vulnerability being discovered that requires a fundamental rethink but that is still is risk whether the standard is official or not and really doesn't speak to the prefixing issue.

Just to be clear, I raise this because the current situation has changed from when the decision was made to prefix. The cost/benefit of prefixing may no longer be as obviously on the side of prefixing. Since the time when the decision was made to prefix: the protocol has gone to last call and been submitted to the IESG, the API changes have landed in W3C draft, and there is now a browser (albeit a dev build) supporting the current protocol in the wild.

For myself: If you can convince Google to prefix, then I will be slightly in favor of keeping the prefix in firefox. If you can't convince them, then my personal opinion is moderately in favor of removing the prefix prior to official release of the firefox with WebSocket enabled.

Anyways, I don't have a vote. But I have been following API and protocol discussions and also following, implementing and testing WebSocket client and server implementations. The facts have changed, and so I'm just suggesting that now might be a good time to revisit.

Comment 41

[Boris Zbarsky [:bzbarsky]]

> I'm saying that the API is unlikely to change in a backwards incompatible way

It just did a few days ago.  The new API doesn't require changes to client code, but does require changes to server code that was expecting to work with the previous API version.  All of which you clearly know...

For what it's worth, Jonas is expecting more API changes to happen in the near future here, and we will likely target Firefox 9 for unprefixing.

Comment 42

[Joel Martin]

I think one problem here is that you are using an odd definition for "WebSocket API". My use of WebSocket API is specifically the Web IDL definition defined by the W3C and WHATWG. I.e. this http://dev.w3.org/html5/websockets/

The WebSocket protocol is not an Application Programming Interface, it is a network protocol and it is defined by the HyBi working group of the IETF here: http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10

I said that the API (not the protocol) is unlikely to change in backwards incompatible ways and that the protocol (not the API) is unlikely to see radical changes.

As far as I can tell, the old API implemented by Chrome stable and by Firefox 4/5 (but disabled), i.e. this http://www.w3.org/TR/2009/WD-websockets-20091029/, is still forwards compatible with the new API definition.

It's possible that the protocol may change in incompatible ways before official publication (I didn't actually say it wouldn't). Regardless, protocol compatibility is a different issue because the server is able to determine from the headers what version of the protocol is being used. WebSocket servers that support more than one protocol version are already the norm. Prefixing the Javascript API in order to "protect" WebSocket servers isn't really a very compelling argument. If Javascript objects were versioned according to the spec revision like the protocol is (not saying that would be a good idea though), then prefixing would be unnecessary.

The API (not the protocol) has not changed in the past few days. I assume you are referring to this: http://html5.org/tools/web-apps-tracker?from=6329&to=6330 But that's not a change in the WebSocket API, that's an explanatory section in the API about what happens at the protocol layer (to reflect the dropping of deflate-stream from the protocol) and that change does not affect the API exposed to Javascript programs.

Certainly I understand the rationale for prefixing. But this isn't a cut and dry issue. WebSockets is more complicated than many previous decisions about prefixing because it involves both a Javascript visible API and a server visible protocol both of which change at different rates and for different reasons.

Like I said, if you can convince Chrome to prefix the API, then great. If not, that seems to nullify many of the benefits of prefixing.

Also, I'm not aware of any discussions, bugs or pending issues that would lead to WebSocket API spec changes (or protocol spec changes for that matter). I'm very interested in being enlightened since it affects projects I'm working on directly. Jonas, care to weigh in?

Anyways, the amount of comment text I've generated today suggests that I care more deeply about this issue than I actually do. Apologies for the noise.

The color of the bikeshed shall be mauve...

Comment 43

[Boris Zbarsky [:bzbarsky]]

> But that's not a change in the WebSocket API

Say we left everything about the WebSocket API the same but changed the explanatory text to say that some entirely different protocol is used on the wire.  Would you consider that an API change?  How is this case different?

> and that change does not affect the API exposed to Javascript programs.

It just affects whether the API actually works against a particular server.

You could similarly argue that changes to what, say, "display: box" actually means don't change what's exposed to the CSS author, just whether it actually works against a particular browser....

From the point of view of exposing to a web page there is really no distinction here between "the api" and "the protocol".  It's a somewhat artificial split more to do with the politics of it all than anything else as far as I can see.

I agree that it's unfortunate that Chrome is already poisoning the well here, but all that means is that pages using websockets will break for Chrome users as they make incompatible protocol changes.  We'd rather not inflict that on our users due to web developers accidentally using an unstable feature, hence the prefixing.

Comment 44

[Michael Platov]

We're supporting websockets since version hixie-76 draft and we never had a problem with changes in JS APIs. Even though underlying protocol and framing changed a lot between draft-00 and draft-10 there were exactly zero changes in our javascript code and was working just fine with any draft/protocol supported by the browser. 

That was until Firefox decided to prefix it for some reason, thus breaking every single website out there that was already successfully using websockets. Now Everyone has to add some meaningless code into the javascript apps JUST to make it work in firefox 6/7 (Chrome, Safari and Opera also support websockets and they don't prefix APIs)  and it would only make things worse if the prefixed versions got released even once, because that would mean that this useless detection code is about to stay for very long time, because some people just won't upgrade their browsers.

I really hope that Javascript prefix will be rolled back in the next Firefox 6/7 beta releases.

Comment 45

[Boris Zbarsky [:bzbarsky]]

Given that Firefox 5 didn't support websockets, why do you have to do anything for 6?  If you just keep the exact code you have, 6 will behave just like 5 (as in, not use the websocket stuff).

The last Firefox 6 beta is done, basically; it's exceedingly unlikely that drivers would approve any change that affects anything web-facing to it.

Comment 46

[Michael Platov]

> Say we left everything about the WebSocket API the same but changed the explanatory text to say that some entirely different protocol is used on the wire.  Would you consider that an API change?  How is this case different?

Just chip in my 5c. It's called Encapsulation. It doesn't matter what happen on the wire (implementation) as long API (interface) is same. Changes between draft-00 and draft-10 are a very good example of this. Not a single change of code using JS API was required, even though there were substantial changes in low-level protocol, masking and framing - things that JS developer will never know/care about. 

As it was already mentioned in this thread, the change in core spec in question was about removing deflate-stream extension from the spec, which btw had no exposure via JS API and was purely an implementation detail (websockets work just fine if browser or server doesn't support this extension).

As Joel Martin already described in great detail, there is really nothing in recent websocket drafts and recent workgroup discussions to justify prefixing in JS APIs. For the 2 years I'm following this standard, I can't recall any backward-incompatible changes in JS-facing APIs, nor I believe that Google/Chrome will shot themselves in the foot by introducing them, especially given the fact that they support websockets in Chrome since version 5 (maybe even 4) and actively participate in the workgroup.

Instead of nice and clean code like this that worked in all browsers :
if ("WebSocket" in window) {
	socket = new WebSocket(url);
}

we now should have something like this (or we have to leave behind our users who love to use firefox, were very happy with Firefox4 release- the first release with websockets support - and were using it since then with the security exception):
if ("WebSocket" in window) {
	socket = new WebSocket(url);
}
else if ("MozWebSocket" in window) {
	socket = new MozWebSocket(url);
}

These "hacks" are not making "the web a better place". In fact, they bring us back to those days, when developers had to include something just to make the thing work in IE.

What's worrying is that if this gets into official release, we'll have to have this hack for a very, very long time, because some people just won't bother to update. Our usage numbers show that about 40% of our users are still not upgraded to Firefox5 and considering how firefox auto-update works, the numbers will be probably be same for Firefox 6.

I understand that it's up to your guys to decide how to name APIs or whether to support some features or not (and thanks a lot for supporting websockets in the first place), but please take another look on this prefixing decision.

Comment 47

[Boris Zbarsky [:bzbarsky]]

> Our usage numbers show that about 40% of our users are still not upgraded to
> Firefox

From Firefox 4?  Firefox 5 is an automatic unprompted update from Firefox 4, so I'm not sure what the "considering" bit is about...

In any case, I'll let Jonas handle your other questions; he had specific API stability concerns here last I checked.

Note also that your argument assumes that the JS developer and the person deploying websockets on the server are not the same entity, right?  From what I've seen they often are the same.

Comment 48

[Eric Shepherd [:sheppy]]

Documentation updated:

https://developer.mozilla.org/en/WebSockets
https://developer.mozilla.org/en/WebSockets/WebSockets_reference/WebSocket

Comment 49

[Rob Hawkes [:rob]]

I'd like to clear up some confusion in the developer community surrounding the use of a capitalised vendor prefix for WebSockets.

Is there a reason for this? I assumed it was because it's a constructor method, whereas something like mozIndexedDb is a method, but not a constructor (it is instantiated with mozIndexedDb.open()).

Comment 50

[Boris Zbarsky [:bzbarsky]]

"Moz" (capital 'M') is the prefix we generally use for DOM things.  That's what CSS2Properties properties use, for example.

I believe that using "moz" for indexeddb was just a mistake...

Comment 51

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

No, we generally use the same capitalization scheme no matter if the property is prefixed or not. This means that properties use camelCase while class names use LeadingCase. So mozIndexedDB, mozBackgroundRequest and mozResponseArrayBuffer are all properties, whereas MozWebSocket and MozBlobBuilder are class names.

CSSOM is a special case since it uses a different capitalization scheme. It capitalizes properties based on where the CSS property name has '-' characters which means prefixing using "Moz" since the CSS property is prefixed using "-moz".

Comment 52

[u279076]

qa-: nothing for QA to verify