Created attachment 8612343 [details] Error message When I try to load Hello by clicking on a URL, it loads a new tab, with a 'join the conversation' button; clicking on that consistently gives the error message, 'something went wrong' and an option to retry. Other notes: 1) the green camera light turns on briefly, then turns off - I have verified allow access to camera+microphone for hello.firefox.com in permissions 2) Hello works perfectly if I click on a conversation from my history, or create a new conversation. The primary perceptible difference there, other than the triggering mechanism, is that it opens in a new broken-out standalone window, not a web browser tab. I will append to this screenshots of my extensions and add-ons, as that may be helpful. It's possible NoScript is the culprit, but I've tried to whitelist. (Please also add more helpful error messages!!)
Okay, I've managed to reproduce this, and the issue is that NoScript, by default, blocks XHR requests to domains that aren't on its whitelist. The standalone client needs to send requests to *.mozilla.com, *.opentok.com, *.mozilla.org, and *.tokbox.com -- and NoScript will block these by default. I can get the standalone client to work with NoScript running by setting "noscript.forbidXHR" to "0" in about:config. It also appears to work if you add all five domains (the four listed above plus firefox.com) to the NoScript whitelist. We should probably reach out to the NoScript developers and ask them to add these domains to the default whitelist. Tagging Giorgio for his input.
Summary: Persistent inability to load Hello by clicking on links → NoScript prevents the Firefox Hello standalone client from running, and it's not clear to users how to allow it.
FWIW: I checked my NS whitelist and I had all five of those domains whitelisted. I'm not positive that fixes the issue.
Criley, it may sound stupid from me to ask, but did you actually try to disable NoScript? Because I'm consistently getting the "something went wrong" error message with NoScript disabled when trying across two different browser profile, both on trunk and on stable (or across the versions). Is this expected and I should test on different machines?
Flags: needinfo?(g.maone) → needinfo?(criley)
Ah - I hadn't tried selectively disabling NoScript, just restarting in Safe Mode. Now that I've tried it, you're absolutely right, NoScript isn't the problem. Privacy Badger, on the other hand, is - disabling EFF's Privacy Badger (v 0.2.6) fixes it. That seems to be the culprit. I think I'll just be leaving that disabled for now...
Changing the summary per Comment 7 (and still wondering why this doesn't work for me even on a clean profile -- maybe plugin related?)
Summary: NoScript prevents the Firefox Hello standalone client from running, and it's not clear to users how to allow it. → EFF's Privacy Badger prevents the Firefox Hello standalone client from running, and it's not clear to users how to allow it.
(In reply to Giorgio Maone from comment #8) > Changing the summary per Comment 7 (and still wondering why this doesn't > work for me even on a clean profile -- maybe plugin related?) Unrelated, but could I have you run through the "try me first" steps at https://wiki.mozilla.org/Loop/Logging#Try_This_First to see if the problem is with Hello, with Firefox, or with your OS/Camera? Thanks!
According to Chris, the server being blocked by Privacy Badger is loop.services.mozilla.com. This is a little perplexing, since that server doesn't store any cookies or anything else that I think can be used for tracking. I haven't been able to reproduce the issue, but given the "learning" nature of this add-on, that's not terribly surprising. Cooper -- I'd be curious about tracking down what we're doing that's triggering Privacy Badger's protections here. Do you have suggestions for figuring out exactly what's going on? Also, given that loop.services.mozilla.com is only used by the Firefox Hello service (that is, it's quite firmly single-domain), I expect that were not doing anything that you would consider to be cross-domain tracking. What would we do to get mozilla.com added to the whitelist?
Sounds like we should add loop.services.mozilla.com and hello.firefox.com to the Privacy Badger yellowlist. Or those domains should post the dnt-policy.txt file :) https://eff.org/dnt-policy
Priority: -- → P4
Hi Adam and Chris, Sorry for the problems here! I tried to reproduce this as well and was unable to, but as Adam said, that is not totally surprising. I expect what is happening here is that mozilla.com or one of its other subdomains was setting a cookie and that's what triggered privacy badger to block loop.services.mozilla.com We don't have a whitelist but we do have a list of things to block cookies from instead of block entirely, to which we could add services.mozilla.com That said, I would like to investigate a bit and confirm my theory here. Chris, would you be willing to jump on the phone with me so that I can walk you through some debugging steps to confirm what is happening here?
Flags: needinfo?(cooperq) → needinfo?(criley)
Hi Cooper - tomorrow (Friday) would be a good day for me, any time 10 am - 1 pm would work well and some gaps after as well. Let me know when you're free?
Taking phone call logistics off list.
Support for Hello/Loop has been discontinued. https://support.mozilla.org/kb/hello-status Hence closing the old bugs. Thank you for your support.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.