Closed Bug 1091016 Opened 10 years ago Closed 10 years ago

Pref network.websocket.enabled is no longer reasonable

Categories

(Core :: Networking: WebSockets, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla36
Tracking Status
firefox35 --- fixed
firefox36 --- fixed

People

(Reporter: yohann.jardin, Assigned: baku)

References

Details

(Keywords: addon-compat, dev-doc-needed)

Attachments

(2 files, 1 obsolete file)

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)
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: nobody → amarchesini
Attached patch pref.patch (obsolete) — Splinter Review
Attachment #8514229 - Flags: review?(bugs)
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+
Attached patch pref.patchSplinter Review
Attachment #8514229 - Attachment is obsolete: true
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/91935dc784ac
Status: NEW → RESOLVED
Closed: 10 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.
Flags: qe-verify-
Flags: needinfo?(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.
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.
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
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?
Attached patch betaSplinter Review
patch for mozilla-beta.
Attachment #8514312 - Flags: approval-mozilla-beta?
Attachment #8537932 - Flags: approval-mozilla-beta?
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+
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
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.
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
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?
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/
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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: