1091016 - Pref network.websocket.enabled is no longer reasonable

Status: RESOLVED FIXED

(Core :: Networking: WebSockets, defect)

Description

[Yohann Jardin]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20141029030207

Steps to reproduce:

1. In about:config, put network.websocket.enabled value to false.
2. Give your firefox hello link to someone
3. Let him call you


Actual results:

The conversation request is received but the panel is empty (except the menu bar)


Expected results:

IMO, when I clicked on Firefox Hello button to get the link, a message saying I can't use it because a pref (network.websocket.enabled) blocks it should be displayed.

Comment 1

[Mark Banner (:standard8)]

Disabling websockets disables the way that Loop gets notified of calls.

Given that network.websocket.enabled is a hidden pref, and there's a warning about fiddling with prefs, I think at best, we should just disable Hello if network.websocket.enabled is false.

However, I'm also wondering if Firefox/Gecko really need this preference now. It looks like it was last changed in 2012 when websockets were turned on by default (bug 472529), and maybe gecko should just remove the pref.

Yohann: It would perhaps be useful if you explain why you've disabled websockets.

Olli: Any idea if it would be safe/sensible to remove the websocket pref now? or if there's use-cases for it being kept?

Comment 2

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

The only theoretical reason for the WebSocket pref these days is the possibility to disable it easily in case there is a security issue found in the protocol itself or so.
But if some major issue was found, I'd expect there to be a new FF build anyhow.

So yes, I'd be in favor of removing the pref and have WebSocket enabled, at least least in the main thread, always.
(We may need another pref for disable WebSocket in workers).

Comment 3

[Andrea Marchesini [:baku]]

Attachment: pref.patch

Comment 4

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

Comment on attachment 8514229 [details] [diff] [review]
pref.patch

>+
>+  var blob = new Blob(Array.prototype.map.call(document.querySelectorAll('script[type="text/js-worker"]'),
>+                                               function (oScript) { return oScript.textContent; }),
Why not give id for the script element and pass
document.getElementById("yourId").textContent to the Blob?

Comment 5

[Andrea Marchesini [:baku]]

Attachment: pref.patch

Comment 6

[Carsten Book [:Tomcat]]

i guess that landed (sorry baku that showed up a little later after our irc conversation)
in https://treeherder.mozilla.org/ui/#/jobs?repo=mozilla-inbound&revision=91935dc784ac and https://hg.mozilla.org/integration/mozilla-inbound/rev/91935dc784ac

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/91935dc784ac

Comment 8

[u279076]

Yohaan, can you please verify this is fixed in tomorrow's Nightly? You'll find it at https://nightly.mozilla.org.

Comment 9

[Yohann Jardin]

I confirm this is fixed for network.websocket.enabled .
However, dom.workers.websocket.enabled do not reproduice what network.websocket.enabled did. When I put this pref to false, firefox hello works as if the value of the pref was true.

Comment 10

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

dom.workers.websocket.enabled is, as the name hints, only about WebSocket support in workers.
Sounds like Hello uses WebSocket in the main thread and that is now enabled by default.

Comment 11

[Andrea Marchesini [:baku]]

Comment on attachment 8514312 [details] [diff] [review]
pref.patch

Approval Request Comment
[Feature/regressing bug #]: 504553
[User impact if declined]: WebSocket enabled in meta
[Describe test coverage new/current, TBPL]: tbpl
[Risks and why]: we want to disable webSocket in workers in beta
[String/UUID change made/needed]: none

Comment 12

[Andrea Marchesini [:baku]]

Attachment: beta

patch for mozilla-beta.

Comment 13

[Jean-Yves Perrier [:teoli]]

dev-doc-needed only to check if we talk about it in the doc, and if so to remove it.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/822004315a45

Comment 15

[Daniel Veditz [:dveditz]]

The Tor folks and others disable this for privacy reasons. Not entirely sure how it's worse than XHR, although for Tor it used to be a problem that it leaked DNS (bug 751465). Is it less of an issue now?

In any case, I found at least 3 addons that turned this off:
 TorBirdy
 OccupyID-1   (the id says TorButton though)
 ILovePrivacy

KeeFox exposes UI for changing the setting but doesn't change the default.

Comment 16

[Chris Tomlinson]

KeeFox doesn't offer any way to change this setting but if connectivity problems indicate that the setting might have been set to false, it does read the setting and issue a warning to users if websockets are disabled.

The removal of this setting has therefore caused an inaccurate message to be displayed to users in very rare circumstances. I'll get a fix rolled out in the next version but it's a low-impact issue (tracked here: https://github.com/luckyrat/KeeFox/issues/386 )

Comment 17

[Jean-Philippe Guérard]

My company proxy filters websockets. Therefore, applications using websockets tend to behave badly.

See http://meta.stackexchange.com/questions/130053/my-corporate-proxy-doesnt-support-web-sockets-which-makes-stack-exchange-a-pai

Without this setting, I've no way to tell firefox that websockets are not working here.

Comment 18

[Patrick McManus [:mcmanus]]

(In reply to Jean-Philippe Guérard from comment #17)
> My company proxy filters websockets. Therefore, applications using
> websockets tend to behave badly.
> 
> See
> http://meta.stackexchange.com/questions/130053/my-corporate-proxy-doesnt-
> support-web-sockets-which-makes-stack-exchange-a-pai
> 
> Without this setting, I've no way to tell firefox that websockets are not
> working here.

I don't know how the filtering works - so I'm curious how the failuure mode is different in between a] pref'd off and b] filtered. Thanks!

Comment 19

[Jean-Philippe Guérard]

(In reply to Patrick McManus [:mcmanus] from comment #18)
> (In reply to Jean-Philippe Guérard from comment #17)
> > My company proxy filters websockets. Therefore, applications using
> > websockets tend to behave badly.
> > 
> > See
> > http://meta.stackexchange.com/questions/130053/my-corporate-proxy-doesnt-
> > support-web-sockets-which-makes-stack-exchange-a-pai
> > 
> > Without this setting, I've no way to tell firefox that websockets are not
> > working here.
> 
> I don't know how the filtering works - so I'm curious how the failuure mode
> is different in between a] pref'd off and b] filtered. Thanks!

The filtered websockets produced a continuous flow of error messages.

Comment 20

[jacobparker1992]

What benefit did it have doing this?! When I want to test websocket fallbacks, I now can't use Firefox 35+.

Comment 21

[Patrick McManus [:mcmanus]]

(In reply to jacobparker1992 from comment #20)
> What benefit did it have doing this?! When I want to test websocket
> fallbacks, I now can't use Firefox 35+.

comment 1

Comment 22

[mkonvisar]

I was trying to sniff the message flow between browser and hypercomments on one site. Was not able to do it, as all messages were sent via WebSocket. Fiddler was not able to capture them as well as firefox dev tools and firebug. So I had to go ff 33 and disable it.
I think it was not a good idea removing setting just for making "Hello" look wokring nice or "...it was last changed in 2012...". To me it looks that lack of specifcation caused wrong implementation and after that we trying to hide this probelm. 
Setting itself is not causing any problem, but "Hello" implementation did. Is there a way to get it back?

Comment 23

[nathan.osman]

For those who want this feature, I've created an add-on that allows you to disable WebSockets: https://addons.mozilla.org/en-US/firefox/addon/websocket-disabler/

Comment 24

[Roland Pihlakas]

For those who want this feature:
You can still disable WebSockets by entering the URL about:config and then searching for

    network.websocket.max-connections

which you can set the value to 0 to prevent new WebSockets from being created.

By the way, I agree that removing the feature was a strange move.