CAPTCHA doesn't load when certain extensions are installed
Categories
(Firefox :: Sync, defect, P3)
Tracking
()
People
(Reporter: hello, Assigned: mconnor)
References
Details
Attachments
(1 file, 3 obsolete files)
6.90 KB,
patch
|
Mardak
:
review+
|
Details | Diff | Splinter Review |
The CAPTCHA doesn't load when some extensions (e.g. NoScript, Adblock Plus, etc) are installed. Weave should figure out how to bypass or add itself to the whitelist so we can side-step this problem. As a temporary measure, we should add a note to the wizard.
Reporter | ||
Updated•14 years ago
|
Reporter | ||
Updated•14 years ago
|
Comment 1•14 years ago
|
||
The patch makes captcha display as-is in an iframe, instead of loading it in a seperate XUL <browser> and extracting the image out of it. This has two effects: - We now comply with ReCaptcha's terms of service which states that the ReCaptcha wordmark must be present in all deployments. - We fallback to a plain HTML page in case Javascript is disabled (using the <noscript> tag), which asks the user to perform additional steps to validate. I looked at how we can circumvent NoScript while the captcha is loading but this proves to be difficult, because: - Adding recaptcha.net to the whitelist does not help. - Temporarily disabling NoScript via the preferences requires a browser restart to take effect, and I couldn't find any other way to do it. In it's current form, the patch will allow users to register even when they have NoScript installed, though the process is a bit cumbersome. AdBlockPlus did not have any effect on the captcha in all my tests.
Updated•14 years ago
|
Reporter | ||
Updated•14 years ago
|
Reporter | ||
Comment 2•14 years ago
|
||
Comment on attachment 393723 [details] [diff] [review] Fallback to <noscript> for Captcha I'm OK with this patch, but we should sync up tomorrow. The switch to about:weave makes this patch sorta obsolete. I copied some of it into about:weave, but have other issues with the captcha there (it's so big).
Updated•14 years ago
|
Comment 3•14 years ago
|
||
We should also try talking to the NoScript developers to see if they can whitelist chrome:// or about: URLs.
Reporter | ||
Updated•14 years ago
|
Updated•14 years ago
|
Assignee | ||
Comment 4•14 years ago
|
||
I'm not sure how this patch ever worked. The manual challenge stuff doesn't seem to work sanely...
Assignee | ||
Updated•14 years ago
|
Updated•14 years ago
|
Comment 5•14 years ago
|
||
We should contact the NoScript devs to see what they did before and if we can just do that again to avoid it being blocked.
Updated•14 years ago
|
Assignee | ||
Comment 6•14 years ago
|
||
Discussed with rags, we're going to punt on this for 1.0. We have a warning for users going into the setup, which seems to have deflected most of this. It's not awesome, but it's good enough to ship. cc-ing mao, to see if there's something easy we can do to make noscript ignore this <browser> element.
Comment 7•14 years ago
|
||
I'm checking what can be done, but if you're importing a 3rd party web script over an insecure connection, I guess most paranoid users won't be happy of this potentially hijackable source being hardcoded in the whitelist, possibly without a mean to remove it. On the other hand, I know first hand (my blog) that recaptcha features a decent noscript fallback. Why doesn't it work for you (per comment 4)?
Comment 8•14 years ago
|
||
OK, I checked and I've seen why the scriptless recaptcha is ugly and disfunctional in your wizard. Good news is that you can easily work around by temporarily whitelisting the following "secure" sources: https://auth.services.mozilla.com https://api-secure.recaptcha.net
Assignee | ||
Comment 9•14 years ago
|
||
Giorgio, is there a simple API we can call to do that in NoScript? I couldn't find my way through the source to find a way to do that.
Comment 10•14 years ago
|
||
Hope this help: <SNIP> var ns = Components.classes["@maone.net/noscript-service;1"] .getService().wrappedJSObject; var disabled = []; ["https://auth.services.mozilla.com", "https://api-secure.recaptcha.net"] .forEach(function(site) { if (!ns.isJSEnabled(site)) { disabled.push(site); // save status ns.setJSEnabled(site, true); // allow site } }); // do whatever you need to... //... and finally reset permissions disabled.forEach(function(site) { ns.setJSEnabled(site, false); }); </SNIP>
Assignee | ||
Updated•13 years ago
|
Assignee | ||
Comment 12•13 years ago
|
||
adds the selected weave server + api-secure.recaptcha.net to the whitelist, if it's not added already, and cleans up on successful account creation or wizard cancel.
Assignee | ||
Updated•13 years ago
|
Comment 13•13 years ago
|
||
Comment on attachment 433408 [details] [diff] [review] fix >+++ b/source/chrome/content/preferences/fx-setup.js >@@ -211,16 +204,53 @@ var gWeaveSetup = { >+ get _remoteSites() { >+ let serverURL = Weave.Service.serverURL; >+ // kinda lame, but NoScript chokes on the trailing slash >+ if (serverURL[serverURL.length - 1] == "/") >+ serverURL = serverURL.substr(0, serverURL.length - 1); serverURL might be a whole path and not just a domain. Does noscript care? >+ _handleNoScript: function (addExceptions) { >+ if (addExceptions) { >+ let self = this; >+ this._remoteSites.forEach(function(site) { >+ if (!ns.isJSEnabled(site)) { >+ self._disabledSites.push(site); // save status >+ ns.setJSEnabled(site, true); // allow site >+ } >+ }); You can pass this as a second argument to forEach and it'll be this inside the function. >+ } >+ else { >+ this._disabledSites.forEach(function(site) { >+ ns.setJSEnabled(site, false); >+ }); >+ this._disabledSites = []; Doesn't matter too much, but why conditionally setJSEnabled(true) and push items into _disabledSites and unconditionally setJSEnabled(false) and set to []?
Comment 14•13 years ago
|
||
(In reply to comment #13) > >+ if (serverURL[serverURL.length - 1] == "/") > >+ serverURL = serverURL.substr(0, serverURL.length - 1); > serverURL might be a whole path and not just a domain. Does noscript care? Yes it does. A "site" for NoScript must be either a prePath (in nsIURI terms) or a host. There's an easy way to satisfy this, by removing the serverURL trailing slash "lame" hack and slightly changing the _handleNoScript() code as follows: this._remoteSites.forEach(function(site) { if (!ns.isJSEnabled(site = ns.getSite(site))) {
Assignee | ||
Updated•13 years ago
|
Assignee | ||
Updated•13 years ago
|
Assignee | ||
Comment 15•13 years ago
|
||
(In reply to comment #13) > (From update of attachment 433408 [details] [diff] [review]) > serverURL might be a whole path and not just a domain. Does noscript care? yes, fixed. > You can pass this as a second argument to forEach and it'll be this inside the > function. right right, fixed > Doesn't matter too much, but why conditionally setJSEnabled(true) and push > items into _disabledSites and unconditionally setJSEnabled(false) and set to > []? Because if one of the domains is already whitelisted, we don't want to muck with that setting.
Assignee | ||
Updated•13 years ago
|
Comment 16•13 years ago
|
||
Comment on attachment 433757 [details] [diff] [review] fix comments Did you attach the wrong patch? Seems the same as the previous one. ?
Assignee | ||
Comment 17•13 years ago
|
||
Bah, yes.
Updated•13 years ago
|
Updated•13 years ago
|
Assignee | ||
Comment 18•13 years ago
|
||
http://hg.mozilla.org/labs/weave/rev/22d53cec2c35
Updated•13 years ago
|
Comment 19•13 years ago
|
||
Verified fix on 1.2b5. noscript and adblock plus works with captcha
Updated•5 years ago
|
Comment 20•4 years ago
|
||
Captcha window does not load in Firefox Quantum 65.0.2 [64 bit.
Was functioning just fine and then suddenly after an auto update [I ass-u-me] as it suddenly would not let the Captcha windoe load and throws a technical error.
Further web pages on a support page I use for a software suite which contains roll down menus to access content do not function anymore as well. If they are rolled down you can select links within, but you cannot roll menu up or roll any other menu down.
Comment 21•4 years ago
|
||
Thanks Jack, but this old bug is related to a specific instance of captcha in s service product that we no longer run. It sounds like your issue is a more general issue with captchas not working in the latest Firefox update, could you please file a fresh bug and provide as much detail as possible about the issue you're seeing?
Description
•