Make "Not Now" the default button for TorBrowser's canvas permission dialogue

added MikePerry201408R TorBrowserTeam201408 component::applications/tor browser owner::isis priority::very high resolution::fixed severity::normal status::closed tbb-linkability tbb-usability type::defect labels

Trac:

Trac:
Description: When TorBrowser's HTML5 canvas permission dialogue pops up from the URL bar,

I suspect that users have no idea what any of that text means, and so they click the largest, most-visible button available on the dialogue box. Right now, that's the "Allow in the Future" button, which allows the site to access HTML5 canvases forever (and until #12682 (moved) and/or #12683 (moved) are fixed, there isn't a way to revoke that permission).

I suggest that we make the largest, most-visible button on this dialogue be the one which doesn't allow the site permission to access HTML5 canvases, i.e. the "Not Now" button, since a site which is trying to do this is overwhelmingly likely to be sourcing some evil ad company's scripts which try to track users. It's not fair to make normal users understand how this works, so let's use people's desires to make popups go away ASAP to their own advantage for their privacy, without making them think too hard about it.

For background info, see this thread on the tor-talk mailing list.

to

When TorBrowser's HTML5 canvas permission dialogue pops up from the URL bar,

I suspect that users have no idea what any of that text means, and so they click the largest, most-visible button available on the dialogue box. Right now, that's the "Allow in the Future" button, which allows the site to access HTML5 canvases forever (and until #12682 (moved) and/or #12683 (moved) are fixed, there isn't a way to revoke that permission).

I suggest that we make the largest, most-visible button on this dialogue be the one which doesn't allow the site permission to access HTML5 canvases, i.e. the "Not Now" button, since a site which is trying to do this is overwhelmingly likely to be sourcing some evil ad company's scripts which try to track users. It's not fair to make normal users understand how this works, so let's use people's desires to make popups go away ASAP to their own advantage for their privacy, without making them think too hard about it.

For background info, see this thread on the tor-talk mailing list.

Trac:
Owner: N/A to mikeperry
Component: Torbutton to Firefox Patch Issues
Priority: major to critical

The dialogue is also vague as to which thing to "Allow in the Future". It could be read as "Allow TorBrowser to send blank canvases in the Future" or "Allow this site to access the canvas in the Future".

I made a simple patch to src/chrome/locale/en/torbutton.properties to fix this, it's in my bug12684-explain-canvas-permissions branch.

This still needs a patch to change the default ordering on the buttons. Gimme a second, the tor-browser repo takes forever to clone.

Trac:
Status: new to needs_revision

Replying to isis:

The dialogue is also vague as to which thing to "Allow in the Future". It could be read as "Allow TorBrowser to send blank canvases in the Future" or "Allow this site to access the canvas in the Future".

I made a simple patch to src/chrome/locale/en/torbutton.properties to fix this, it's in my bug12684-explain-canvas-permissions branch.

I wonder whether we really want to make the text in the popup even longer given that a lot of people are presumably stopping to read it while trying to parse the first sentence. So, maybe we should be smarter here and rephrase the whole dialog in a way that fixes both problems.

Just to add to the fun: I now click elsewhere on the page to make the popup go away, rather than trying to select one of the choices (or click the x). That's because I once tried to click the "allow in the future" in order to pull it down and find other options (like "definitely no"), but somehow I ended up selecting allow and never got to see the other options.

Maybe just my inability to use the interface, but I'm a data point.

#10144 (moved) about this ticket too.

Replying to gk:

Replying to isis:

The dialogue is also vague as to which thing to "Allow in the Future". It could be read as "Allow TorBrowser to send blank canvases in the Future" or "Allow this site to access the canvas in the Future".

I made a simple patch to src/chrome/locale/en/torbutton.properties to fix this, it's in my bug12684-explain-canvas-permissions branch.

I wonder whether we really want to make the text in the popup even longer given that a lot of people are presumably stopping to read it while trying to parse the first sentence. So, maybe we should be smarter here and rephrase the whole dialog in a way that fixes both problems.

I agree, actually. I just thought adding more explanation was clearer and more likely to get merged than rewriting the whole UI string. But if everyone is opting for shorter messages... then scrap my last patch.

FWIW, I tried to patch TorBrowser, in tor-browser.git/browser/base/content/browser.js, around L6030:

diff --git i/browser/base/content/browser.js w/browser/base/content/browser.js
index 1df295a..d22058b 100644
--- i/browser/base/content/browser.js
+++ w/browser/base/content/browser.js
@@ -6076,13 +6076,7 @@ var CanvasPermissionPromptHelper = {
 
     var message = getLocalizedString("canvas.siteprompt", [ uri.asciiHost ]);
 
-    var mainAction = {
-      label: getLocalizedString("canvas.allow"),
-      accessKey: getLocalizedString("canvas.allowAccessKey"),
-      callback: function() {
-          setCanvasPermission(uri, Ci.nsIPermissionManager.ALLOW_ACTION);
-      }
-    };
+    var mainAction = null; /* Not now */
 
     var secondaryActions = [
       {
@@ -6091,7 +6085,14 @@ var CanvasPermissionPromptHelper = {
         callback: function() {
           setCanvasPermission(uri, Ci.nsIPermissionManager.DENY_ACTION);
         }
-      }
+      },
+      {
+        label: getLocalizedString("canvas.allow"),
+        accessKey: getLocalizedString("canvas.allowAccessKey"),
+        callback: function() {
+            setCanvasPermission(uri, Ci.nsIPermissionManager.ALLOW_ACTION);
+        }
+      }    
     ];
 
     // Since we have a process in place to perform localization for the

I re-zipped that into tor-browser_en-US/Browser/browser/omni.ja in my browser tree, and restarted the browser several times, but debug logs gave me no idea why it wasn't running. And MDN didn't help. Bad JS syntax? Any idea what I did wrong?

Replying to isis:

FWIW, I tried to patch TorBrowser, in tor-browser.git/browser/base/content/browser.js, around L6030:

I re-zipped that into tor-browser_en-US/Browser/browser/omni.ja in my browser tree, and restarted the browser several times, but debug logs gave me no idea why it wasn't running. And MDN didn't help. Bad JS syntax? Any idea what I did wrong?

Not yet. But given the patch you tried it is probably not the one you really want: https://mxr.mozilla.org/mozilla-esr24/source/toolkit/modules/PopupNotifications.jsm#198

Replying to arma:

Just to add to the fun: I now click elsewhere on the page to make the popup go away, rather than trying to select one of the choices (or click the x). That's because I once tried to click the "allow in the future" in order to pull it down and find other options (like "definitely no"), but somehow I ended up selecting allow and never got to see the other options.

Maybe just my inability to use the interface, but I'm a data point.

Ah ha! My problem was that I clicked on "allow in the future" and tried to drag it down to other options. It turns out I have to click on the triangle and drag it down. This is unintuitive to me.

Replying to arma:

Replying to arma:

Just to add to the fun: I now click elsewhere on the page to make the popup go away, rather than trying to select one of the choices (or click the x). That's because I once tried to click the "allow in the future" in order to pull it down and find other options (like "definitely no"), but somehow I ended up selecting allow and never got to see the other options.

Maybe just my inability to use the interface, but I'm a data point.

Ah ha! My problem was that I clicked on "allow in the future" and tried to drag it down to other options. It turns out I have to click on the triangle and drag it down. This is unintuitive to me.

It has never occurred to me to drag anything anywhere!

Everyone seems to have a differently wrong way to interact with this UI, clearly "we're all adorable little unique snowflakes" (in phobos' words). And clearly, this UI is borked.

I have a new patch for this. I'm going to combine it with the proposed patch for #7265 (closed) and try to build.

The patch is this commit in my tor-browser repo in the bug12684-canvas-dialogue-order branch. It requires an additional patch to TorButton to add necessary UI strings.

I've also added another TorButton patch to clarify the explanation strings, and decapitalise some of the other strings in this UI (to make them match Mozilla's casing). Both TorButton patches are in my bug12684-additional-canvas-ui-strings branch.

Trac:
Status: needs_revision to needs_review

Trac:
Keywords: N/A deleted, MikePerry201407R added

Trac:
Keywords: N/A deleted, TorBrowserTeam201407 added

Looks good to me. Thanks isis! The only thing I am a bit unhappy with is that you now have the "Not now" option twice available if the drop down menu is open. That might be confusing to some users ("Why is there an additional 'Not now' and what is it doing compared to the already selected one?"). But I am happy if that is handled in a different bug if that is bothering users at all...

Replying to gk:

Looks good to me. Thanks isis! The only thing I am a bit unhappy with is that you now have the "Not now" option twice available if the drop down menu is open. That might be confusing to some users ("Why is there an additional 'Not now' and what is it doing compared to the already selected one?"). But I am happy if that is handled in a different bug if that is bothering users at all...

Thanks! But... le sigh.

I couldn't figure out the PopupNotification.jsm API very well... I was never able to determine where the default Mozilla [x] Not now array item was coming from, nor how to disable/change it.

I'd prefer to just do it right, and not substitute one confusing UI for a slightly-less-confusing UI. Do you know where the default secondaryActions array item comes from, gk?

Replying to isis:

Replying to gk:

Looks good to me. Thanks isis! The only thing I am a bit unhappy with is that you now have the "Not now" option twice available if the drop down menu is open. That might be confusing to some users ("Why is there an additional 'Not now' and what is it doing compared to the already selected one?"). But I am happy if that is handled in a different bug if that is bothering users at all...

Thanks! But... le sigh.

I couldn't figure out the PopupNotification.jsm API very well... I was never able to determine where the default Mozilla [x] Not now array item was coming from, nor how to disable/change it.

I'd prefer to just do it right, and not substitute one confusing UI for a slightly-less-confusing UI. Do you know where the default secondaryActions array item comes from, gk?

That is not part of the secondaryActions array. It is rather "hard-coded" in the popup-notification XBL binding, I think: https://mxr.mozilla.org/mozilla-esr24/source/toolkit/content/widgets/notification.xml#477

Trac:
Cc: isis, mikeperry, gk to isis, mikeperry, gk, brade, mcs

Trac:

Make "Not Now" the default button for TorBrowser's canvas permission dialogue

Child items 0

Activity