Opened 3 months ago

Closed 3 months ago

#27543 closed defect (fixed)

QR code on http://web.whatsapp.com is only shortly visible in Tor Browser 8

Reported by: gk Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-8.0-issues, tbb-regression, tbb-8.0.1-can, GeorgKoppen201809, TorBrowserTeam201809R
Cc: semmyru Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

A user reported on the blog that with the update to Tor Browser 8 the QR code on http://web.whatsapp.com shows up but quickly afterwards vanishes again which makes it de facto not possible to get it.

I could repro on Linux.

Child Tickets

Change History (12)

comment:2 Changed 3 months ago by gk

Cc: semmyru added

Closed #27598 as duplicate.

comment:3 Changed 3 months ago by gk

Keywords: tbb-8.0.1-can added

Marking for 8.0.1 can.

comment:4 Changed 3 months ago by gk

Keywords: GeorgKoppen201809 added

comment:5 Changed 3 months ago by gk

Keywords: TorBrowserTeam201809R added
Status: newneeds_review

Seems we need to flip privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts to false here as well, until the Mozilla bug gets fixed. I did that in bug_27543 (https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_27543&id=ce60de442f949393b7f24acd153f82a57d78fe0e) in my public tor-browser repository. Please review.

comment:6 Changed 3 months ago by gk

Hm, I wonder whether we want to switch the default button being selected to "Don't Allow". Having the scary warning on the dialog ("This may be used to uniquely identify your computer.") does not really seem to fit to having the allow options pre-selected, just one click away.

comment:7 Changed 3 months ago by gk

It seems a simple patch like

diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js
index 443619533567..85be5923c509 100644
--- a/browser/base/content/browser.js
+++ b/browser/base/content/browser.js
@@ -6855,23 +6855,23 @@ var CanvasPermissionPromptHelper = {
                     : Ci.nsIPermissionManager.EXPIRE_SESSION);
     }
 
-    let mainAction = {
+    let secondaryActions = [{
       label: gNavigatorBundle.getString("canvas.allow"),
       accessKey: gNavigatorBundle.getString("canvas.allow.accesskey"),
       callback(state) {
         setCanvasPermission(Ci.nsIPermissionManager.ALLOW_ACTION,
                             state && state.checkboxChecked);
       }
-    };
+    }];
 
-    let secondaryActions = [{
+    let mainAction = {
       label: gNavigatorBundle.getString("canvas.notAllow"),
       accessKey: gNavigatorBundle.getString("canvas.notAllow.accesskey"),
       callback(state) {
         setCanvasPermission(Ci.nsIPermissionManager.DENY_ACTION,
                             state && state.checkboxChecked);
       }
-    }];
+    };

would fix that part.

comment:8 Changed 3 months ago by gk

Ooookay, so the reason for allowing to be the default action is:

By our UX convention, the main action is always the positive/allow choice, while the secondary action is the negative/deny choice. Not breaking this pattern is important to avoid messing with user intuition.

(see: https://bugzilla.mozilla.org/show_bug.cgi?id=967895#c31)

Last edited 3 months ago by gk (previous) (diff)

comment:9 in reply to:  6 ; Changed 3 months ago by pospeselr

Replying to gk:

Seems we need to flip privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts to false here as well, until the Mozilla bug gets fixed. I did that in bug_27543 (https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_27543&id=ce60de442f949393b7f24acd153f82a57d78fe0e) in my public tor-browser repository. Please review.

Unless I'm misundersanding things, it looks like you'll have to backport some code in CanvasUtils.cpp for that option to do anything ( https://searchfox.org/mozilla-central/source/dom/canvas/CanvasUtils.cpp#146 ).

Last edited 3 months ago by pospeselr (previous) (diff)

comment:10 in reply to:  9 ; Changed 3 months ago by gk

Replying to pospeselr:

Replying to gk:

Seems we need to flip privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts to false here as well, until the Mozilla bug gets fixed. I did that in bug_27543 (https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_27543&id=ce60de442f949393b7f24acd153f82a57d78fe0e) in my public tor-browser repository. Please review.

Unless I'm misundersanding things, it looks like you'll have to backport some code in CanvasUtils.cpp for that option to do anything ( https://searchfox.org/mozilla-central/source/dom/canvas/CanvasUtils.cpp#146 ).

No, https://bugzilla.mozilla.org/show_bug.cgi?id=1376865 has all we need already, I think (and made it into ESR 60).

comment:11 in reply to:  10 Changed 3 months ago by pospeselr

Replying to gk:

Replying to pospeselr:

Replying to gk:

Seems we need to flip privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts to false here as well, until the Mozilla bug gets fixed. I did that in bug_27543 (https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_27543&id=ce60de442f949393b7f24acd153f82a57d78fe0e) in my public tor-browser repository. Please review.

Unless I'm misundersanding things, it looks like you'll have to backport some code in CanvasUtils.cpp for that option to do anything ( https://searchfox.org/mozilla-central/source/dom/canvas/CanvasUtils.cpp#146 ).

No, https://bugzilla.mozilla.org/show_bug.cgi?id=1376865 has all we need already, I think (and made it into ESR 60).

Ah my mistake, the pref getter is wrapped in the 'DOM_PREF' macro in /dom/base/DOMPrefsInternal.h which is used. This patch looks good to me!

comment:12 Changed 3 months ago by gk

Resolution: fixed
Status: needs_reviewclosed

Thanks! Cherry-picked to tor-browser-60.2.0esr-8.5-1 (commit 3b34acd2d3b755cef2fbd83ddf37545b6988eb0f) and tor-browser-60.2.0esr-8.0-1 (commit 367ce17b735fdfa1244aa78569e16ac6c90dd746).

Note: See TracTickets for help on using tickets.