Opened 5 years ago

Closed 4 years ago

Last modified 3 years ago

#12684 closed defect (fixed)

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

Reported by: isis Owned by: isis
Priority: Very High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-usability, tbb-linkability, MikePerry201408R, TorBrowserTeam201408
Cc: isis, mikeperry, gk, brade, mcs Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by isis)

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

https://trac.torproject.org/projects/tor/raw-attachment/ticket/12684/tlk.io-canvas-access.png

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 and/or #12683 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.

Child Tickets

Attachments (9)

tlk.io-canvas-access.png (22.8 KB) - added by isis 5 years ago.
torbrowser-canvas-fingerprinting-UI_0.jpg (375.3 KB) - added by isis 5 years ago.
torbrowser-canvas-fingerprinting-UI_1.jpg (132.8 KB) - added by isis 5 years ago.
torbrowser-canvas-fingerprinting-UI_3.jpg (146.5 KB) - added by isis 5 years ago.
torbrowser-canvas-fingerprinting-UI_4.jpg (141.3 KB) - added by isis 5 years ago.
torbrowser-canvas-fingerprinting-UI_5.jpg (206.3 KB) - added by isis 5 years ago.
canvas-tweet-1.png (238.7 KB) - added by isis 5 years ago.
canvas-tweet-2.png (109.0 KB) - added by isis 5 years ago.
html5canvasWin7.png (7.0 KB) - added by bugzilla 4 years ago.

Download all attachments as: .zip

Change History (52)

Changed 5 years ago by isis

Attachment: tlk.io-canvas-access.png added

comment:1 Changed 5 years ago by isis

Description: modified (diff)

comment:2 Changed 5 years ago by mikeperry

Component: TorbuttonFirefox Patch Issues
Owner: set to mikeperry
Priority: majorcritical

comment:3 Changed 5 years ago by isis

Status: newneeds_revision

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.

comment:4 in reply to:  3 ; Changed 5 years ago by 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.

comment:5 Changed 5 years ago by 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.

comment:6 Changed 5 years ago by cypherpunks

#10144 about this ticket too.

comment:7 in reply to:  4 ; Changed 5 years ago by isis

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?

comment:8 in reply to:  7 Changed 5 years ago by gk

Replying to isis:

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

<snip>

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

comment:9 in reply to:  5 ; Changed 5 years ago by 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.

comment:10 in reply to:  9 Changed 5 years ago by isis

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.

comment:11 Changed 5 years ago by isis

Status: needs_revisionneeds_review

I have a new patch for this. I'm going to combine it with the proposed patch for #7265 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.

comment:12 Changed 5 years ago by gk

Keywords: MikePerry201407R added

comment:13 Changed 5 years ago by gk

Keywords: TorBrowserTeam201407 added

comment:14 Changed 5 years ago by 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...

comment:15 in reply to:  14 ; Changed 5 years ago by 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?

comment:16 in reply to:  15 Changed 5 years ago by 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

comment:17 Changed 5 years ago by mcs

Cc: brade mcs added

Changed 5 years ago by isis

Changed 5 years ago by isis

comment:18 Changed 5 years ago by isis

Okay, here's what my current problems are, and what the UI looks like:

https://trac.torproject.org/projects/tor/raw-attachment/ticket/12684/torbrowser-canvas-fingerprinting-UI_1.jpg

Problem #1: That <separator class="groove"> part between the sentences. For the life of me, I can't get this thing to insert a newline. I've tried \n\n, a XUL separator and a XUL spacer. All of them actually show up in the text.

Problem #2: The Not Now thing is duplicated, as gk pointed out. Patching this would be a giant mess and would require more Firefox patches. I could make the Never for this site be the default, and get rid of the first Not Now, if people think that Never is an okay default.


I've also added a freely-licenced icon for this popup, to replace the question mark, but that was more Firefox patches and I haven't rebuilt yet.

comment:19 in reply to:  18 ; Changed 5 years ago by mcs

Replying to isis:

Problem #2: The Not Now thing is duplicated, as gk pointed out. Patching this would be a giant mess and would require more Firefox patches. I could make the Never for this site be the default, and get rid of the first Not Now, if people think that Never is an okay default.

In Firefox 31, there is an option to hide the built-in "Not Now" menu item. See:
http://mxr.mozilla.org/mozilla-esr31/source/toolkit/modules/PopupNotifications.jsm#270

Should we wait until after TB adopts ESR 31 to fix the duplicate "Not Now" problem?

comment:20 Changed 5 years ago by mikeperry

Keywords: MikePerry201408R TorBrowserTeam201408 added; MikePerry201407R TorBrowserTeam201407 removed

comment:21 in reply to:  18 ; Changed 5 years ago by mcs

Replying to isis:

Problem #1: That <separator class="groove"> part between the sentences. For the life of me, I can't get this thing to insert a newline. I've tried \n\n, a XUL separator and a XUL spacer. All of them actually show up in the text.

The text ends up in a XUL <description> element. If we can apply a CSS rule like white-space: pre-wrap, then newlines (\n) will not be ignored. There might be a better way, but here is something that seems to work: add the following code to the CanvasPermissionPromptHelper_init() function:

if (document.styleSheets && (document.styleSheets.length > 0)) try {
  let ruleText = "panel[popupid=canvas-permissions-prompt] description { white-space: pre-wrap";
  let sheet = document.styleSheets[0];
  sheet.insertRule(ruleText, sheet.cssRules.length);
} catch (e) {}

comment:22 Changed 5 years ago by mikeperry

Owner: changed from mikeperry to isis
Status: needs_reviewassigned

comment:23 Changed 5 years ago by mikeperry

Status: assignedneeds_review

Trac cannot change assignment without resetting ticket state...

comment:24 in reply to:  19 Changed 5 years ago by isis

Replying to mcs:

Replying to isis:

Problem #2: The Not Now thing is duplicated, as gk pointed out. Patching this would be a giant mess and would require more Firefox patches. I could make the Never for this site be the default, and get rid of the first Not Now, if people think that Never is an okay default.

In Firefox 31, there is an option to hide the built-in "Not Now" menu item. See:
http://mxr.mozilla.org/mozilla-esr31/source/toolkit/modules/PopupNotifications.jsm#270

Should we wait until after TB adopts ESR 31 to fix the duplicate "Not Now" problem?


I think this is the right way to go.

comment:25 in reply to:  21 ; Changed 5 years ago by isis

Status: needs_reviewneeds_information

Replying to mcs:

Replying to isis:

Problem #1: That <separator class="groove"> part between the sentences. For the life of me, I can't get this thing to insert a newline. I've tried \n\n, a XUL separator and a XUL spacer. All of them actually show up in the text.

The text ends up in a XUL <description> element. If we can apply a CSS rule like white-space: pre-wrap, then newlines (\n) will not be ignored. There might be a better way, but here is something that seems to work: add the following code to the CanvasPermissionPromptHelper_init() function:

if (document.styleSheets && (document.styleSheets.length > 0)) try {
  let ruleText = "panel[popupid=canvas-permissions-prompt] description { white-space: pre-wrap";
  let sheet = document.styleSheets[0];
  sheet.insertRule(ruleText, sheet.cssRules.length);
} catch (e) {}


Okay, I added that stanza after the

Services.obs.addObserver(this, this._permissionsPrompt, false);


line, and rebuilt Firefox. However, the resulting build was all kinds of broken, and running the firefox binary with -jsconsole had some errors about unterminated string literals in browser/content/browser.js.

I thought it was due to the missing CSS } at the end of the ruleText variable above, but after adding the } and rebuilding a second time it still came out janky and broken.

Was I supposed to add the CSS hack before the ServiceObserver gets added?

comment:26 in reply to:  25 Changed 5 years ago by isis

Status: needs_informationneeds_revision

Replying to isis:

Was I supposed to add the CSS hack before the ServiceObserver gets added?


Yep, it needed to go before the ServiceObserver gets added. Everything works great now.

Here's what it looks like:

https://trac.torproject.org/projects/tor/raw-attachment/ticket/12684/torbrowser-canvas-fingerprinting-UI_3.jpg

The only thing not working is my patch to change the (?) question mark icon into a little (freely-licensed) painter's palette. I think I just put the icon files in the wrong folder, probably. It's kind of hard to tell where files end up when the whole browser is built.

And, obviously, as mentioned previously, the double "Not Now" thing will have to wait until FF31 to get fixed.

Last edited 5 years ago by isis (previous) (diff)

Changed 5 years ago by isis

Changed 5 years ago by isis

comment:27 Changed 5 years ago by isis

I got one part of the icon working (in the URL bar) but not the main one in the PopupNotification...

https://trac.torproject.org/projects/tor/raw-attachment/ticket/12684/torbrowser-canvas-fingerprinting-UI_4.jpg

comment:28 in reply to:  27 ; Changed 5 years ago by mcs

Replying to isis:

I got one part of the icon working (in the URL bar) but not the main one in the PopupNotification...

You might be able to figure out by example what changes are needed and where to put the icon file, e.g.,

http://mxr.mozilla.org/mozilla-esr24/search?string=Geolocation-64.png
and
http://mxr.mozilla.org/mozilla-esr24/find?text=&string=Geolocation-64.png

comment:29 in reply to:  28 Changed 5 years ago by isis

Replying to mcs:

Replying to isis:

I got one part of the icon working (in the URL bar) but not the main one in the PopupNotification...

You might be able to figure out by example what changes are needed and where to put the icon file, e.g.,

http://mxr.mozilla.org/mozilla-esr24/search?string=Geolocation-64.png
and
http://mxr.mozilla.org/mozilla-esr24/find?text=&string=Geolocation-64.png


Thanks! I missed that I was supposed to declare the resources in the jar.mn files.

Changed 5 years ago by isis

comment:30 Changed 5 years ago by isis

Status: needs_revisionneeds_review

I think I'm done! Review and suggestions welcome!

Here's what it looks like now:

https://trac.torproject.org/projects/tor/raw-attachment/ticket/12684/torbrowser-canvas-fingerprinting-UI_5.jpg

The only thing that I'm a tiny bit dissatisfied with is that the larger palette icon is a little bit pixelly.

comment:31 Changed 5 years ago by isis

The torbutton string changes are in my bug12684-additional-canvas-ui-strings branch, and a squashed version, condensed into a single commit, is in my bug12684-additional-canvas-ui-strings_squashed branch.

The tor-browser changes are in my bug12684-canvas-dialogue-order_r1 branch (based upon tor-browser-24.7.0esr-4.x-2), and a condensed version of everything all in one commit is in my bug12684-canvas-dialogue-order_r1_squashed branch.

comment:32 in reply to:  30 ; Changed 5 years ago by mcs

Replying to isis:

The only thing that I'm a tiny bit dissatisfied with is that the larger palette icon is a little bit pixelly.

Is this the same image? http://www.i2clipart.com/clipart-palette-3f87
There is an SVG available, which at a glance seems to scale nicely.

comment:33 Changed 5 years ago by lunar

“HTML5 canvas” is a technical concept. Maybe it would be worth giving an example of when HTML5 canvas are useful past tracking users? I'm thinking of something like: Unless this website performs complex drawings (e.g. a game), you should not allow it to proceed.

But then, while I'm thinking about it, the current UI might be entirely wrong here. HTML5 canvas access should be blocked by default. A small warning should be displayed on the top of the page (like when NoScript blocks XSS), alongside an “Option” button where access can be allowed. “I can see the website does not work as it should, I need allow this thing that has been blocked.” And then I don't need to get a deep understanding of what “HTML5 canvases” are.

But the recent changes are already improvements and the latter idea should probably belongs to a separate ticket.

comment:34 in reply to:  32 Changed 5 years ago by isis

Replying to mcs:

Replying to isis:

The only thing that I'm a tiny bit dissatisfied with is that the larger palette icon is a little bit pixelly.

Is this the same image? http://www.i2clipart.com/clipart-palette-3f87
There is an SVG available, which at a glance seems to scale nicely.


Hey, thanks for finding that! It is the same image.

I've committed the .svg file instead of the .png as a fixup! commit, and rebased my changes into my bug12684-canvas-dialogue-order_r2 branch (or the bug12684-canvas-dialogue-order_r2_squashed branch for the smooshed version).

I rebuilt Firefox and the using the .svg works great (modulo whatever concerns about SVG being an even shittier image format than PNG). Your call; you've got both sets of branches now.

comment:35 in reply to:  33 ; Changed 5 years ago by isis

Replying to lunar:

“HTML5 canvas” is a technical concept. Maybe it would be worth giving an example of when HTML5 canvas are useful past tracking users? I'm thinking of something like: Unless this website performs complex drawings (e.g. a game), you should not allow it to proceed.



Like these examples?

https://trac.torproject.org/projects/tor/raw-attachment/ticket/12684/canvas-tweet-2.png

https://trac.torproject.org/projects/tor/raw-attachment/ticket/12684/canvas-tweet-1.png

So... I was actually being entirely sarcastic when I said that the above was a legit use for accessing HTML5 canvas image data. It's not. It really is just malware. Even that Glitch Art Generator site, which at first glance might seem legitimate, totally isn't. There's no reason, as far as I can tell, why that site couldn't just upload the image file to the server and have the editing happen server-side, or render it to an HTML5 canvas and have the user edit it locally in the browser (without ever uploading/extracting at all).

If there is a legitimate reason that any site would ever need to render an image to an HTML5 canvas and then extract the locally rendered image data, I do not know of it. Even HTML5 games shouldn't need to do this. Lazy webdevs, crap code, and even crappier W3C specifications advocating privacy by policy.

There is one possible exception, as far as I've seen: Sites such as Twitter use HTML5 canvas image data extraction to build profile pages: they force you to "upload" your image file by rendering it to a canvas locally, then they extract the HTML5 canvas data (which is where the actual "uploading" of the image occurs). This is done so that the user can drag their photos around while updating their profile page, e.g. rotating, resizing, etc. Then the rotated/resized/whatever photo from the canvas gets uploaded, rather than the original. However "legitimate" and "benign" this may seem, it can still be used to fingerprint users, and therefore I would argue that it's still crappy code produced by lazy webdevs who don't really care about their users' privacy.

(Dear Twitter, Github, Etherpad, and that Glitch Art Generator thing developers: if you're reading this, sorry for being rude, and please pretty please consider fixing your code.)



But then, while I'm thinking about it, the current UI might be entirely wrong here. HTML5 canvas access should be blocked by default.


It is! Tor Browser sends a blank (white) image, of static size, by default (and thereafter, if the user has clicked the Never for this site button in the popup).



A small warning should be displayed on the top of the page (like when NoScript blocks XSS), alongside an “Option” button where access can be allowed. “I can see the website does not work as it should, I need allow this thing that has been blocked.” And then I don't need to get a deep understanding of what “HTML5 canvases” are. But the recent changes are already improvements and the latter idea should probably belongs to a separate ticket.


Hmm. I'm not sure I actually understand what you're suggesting. Do you mean that the popup should say I can see this website (example.com) does not work as it should...? Because that would encourage users to allow HTML5 canvas access (which we definitely don't want them doing!).

Or perhaps I've misunderstood you? Would you please explain your idea more? Perhaps on a new ticket, if you like.

Last edited 5 years ago by isis (previous) (diff)

Changed 5 years ago by isis

Attachment: canvas-tweet-1.png added

Changed 5 years ago by isis

Attachment: canvas-tweet-2.png added

comment:36 Changed 5 years ago by mikeperry

Resolution: fixed
Status: needs_reviewclosed

Ok, I merged the r2_squashed version of this into both our 3.x and 4.x branches. I *think* I agree with isis that we don't want to give people the impression that the is OK to allow under certain circumstances, because then we open up the ability for sites to social engineer people into getting fingerprinted.

I still tried to clarify the strings to repeat "image data" for emphasis, but I'm not sure its any better. Note also we want to prefer brevity for this popup, so we're kind of extra-constrained. Here's the new Torbutton string:
https://gitweb.torproject.org/torbutton.git/commitdiff/402eb5d24ba35aef68ecbe95d77fa3c5c0768d29

comment:37 in reply to:  35 Changed 5 years ago by lunar

Replying to isis:

A small warning should be displayed on the top of the page (like when NoScript blocks XSS), alongside an “Option” button where access can be allowed. “I can see the website does not work as it should, I need allow this thing that has been blocked.” And then I don't need to get a deep understanding of what “HTML5 canvases” are. But the recent changes are already improvements and the latter idea should probably belongs to a separate ticket.


Hmm. I'm not sure I actually understand what you're suggesting.

I'm suggesting to use the same notifications used by the pop-up blocker. See:

http://www.americanancestors.org/uploadedImages/American_Ancestors/Content/Help/pop_up_firefox_1.jpg

The browser would say Tor Browser prevented this site from extracting a dynamically rendered image to protect your privacy. The option button would offer allow once / always allow options.

Changed 4 years ago by bugzilla

Attachment: html5canvasWin7.png added

comment:38 Changed 4 years ago by bugzilla

Component: Firefox Patch IssuesTor Browser
Resolution: fixed
Severity: Normal
Status: closedreopened

It seems to be a regression of this ticket.
Here is how it looks like on Win7:

comment:39 in reply to:  38 ; Changed 4 years ago by isis

Resolution: fixed
Status: reopenedclosed

Replying to bugzilla:

It seems to be a regression of this ticket.
Here is how it looks like on Win7:


Yep, that's how it is supposed to look! "Not Now" is supposed to be the default.

comment:40 in reply to:  39 Changed 4 years ago by bugzilla

Replying to isis:

Yep, that's how it is supposed to look! "Not Now" is supposed to be the default.

How nice. Don't you think that something is missing? (Icons ;)

Last edited 4 years ago by bugzilla (previous) (diff)

comment:41 Changed 4 years ago by bugzilla

Resolution: fixed
Status: closedreopened

Is this ticket responsible for icons?
Also propose to add a lock to icon to notify user that he was protected. And remove popup-ing!

comment:42 in reply to:  38 ; Changed 4 years ago by gk

Resolution: fixed
Status: reopenedclosed

Replying to bugzilla:

It seems to be a regression of this ticket.

Please, file a new ticket. Ideally, if it is a regression, mentioning the first version that broke.

comment:43 in reply to:  42 Changed 3 years ago by bugzilla

Replying to gk:

Please, file a new ticket. Ideally, if it is a regression, mentioning the first version that broke.

It was a Firefox bug which was fixed somewhere in transition to FF45ESR.

Note: See TracTickets for help on using tickets.