Pref network.websocket.enabled is no longer reasonable

RESOLVED FIXED in Firefox 35

Status

()

Core
Networking: WebSockets
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: Yohann Jardin, Assigned: baku)

Tracking

({addon-compat, dev-doc-needed})

unspecified
mozilla36
x86_64
Windows 7
addon-compat, dev-doc-needed
Points:
---
Bug Flags:
in-testsuite +
qe-verify -

Firefox Tracking Flags

(firefox35 fixed, firefox36 fixed)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

3 years ago
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.
Component: General → Client
Product: Core → Loop
QA Contact: anthony.s.hughes
Version: 36 Branch → unspecified
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?
Flags: needinfo?(bugs)

Comment 2

3 years ago
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).
Flags: needinfo?(bugs)
(Assignee)

Updated

3 years ago
Assignee: nobody → amarchesini
(Assignee)

Comment 3

3 years ago
Created attachment 8514229 [details] [diff] [review]
pref.patch
Attachment #8514229 - Flags: review?(bugs)

Comment 4

3 years ago
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?
Attachment #8514229 - Flags: review?(bugs) → review+
(Assignee)

Comment 5

3 years ago
Created attachment 8514312 [details] [diff] [review]
pref.patch
Attachment #8514229 - Attachment is obsolete: true
(Assignee)

Updated

3 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: checkin-needed
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
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/91935dc784ac
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Yohaan, can you please verify this is fixed in tomorrow's Nightly? You'll find it at https://nightly.mozilla.org.
status-firefox36: --- → fixed
Flags: qe-verify-
Flags: needinfo?(yohann.jardin)
(Reporter)

Comment 9

3 years ago
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.
Flags: needinfo?(yohann.jardin)
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.

Updated

3 years ago
Component: Client → Networking: WebSockets
Product: Loop → Core
QA Contact: anthony.s.hughes
Summary: Firefox hello should inform when network.websocket.enabled=false → Pref network.websocket.enabled is no longer reasonable
(Assignee)

Comment 11

3 years ago
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
Attachment #8514312 - Flags: approval-mozilla-beta?
(Assignee)

Comment 12

3 years ago
Created attachment 8537932 [details] [diff] [review]
beta

patch for mozilla-beta.
(Assignee)

Updated

3 years ago
Attachment #8514312 - Flags: approval-mozilla-beta?
(Assignee)

Updated

3 years ago
Attachment #8537932 - Flags: approval-mozilla-beta?
(Assignee)

Updated

3 years ago
Blocks: 1112054
dev-doc-needed only to check if we talk about it in the doc, and if so to remove it.
Keywords: dev-doc-needed
Attachment #8537932 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
https://hg.mozilla.org/releases/mozilla-beta/rev/822004315a45
status-firefox35: --- → fixed
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.
Keywords: addon-compat

Comment 16

2 years ago
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 )
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.
(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!
(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

2 years ago
What benefit did it have doing this?! When I want to test websocket fallbacks, I now can't use Firefox 35+.
(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

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

2 years ago
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/
You need to log in before you can comment on or make changes to this bug.