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

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.

added GeorgKoppen201809 TorBrowserTeam201809R component::applications/tor browser owner::tbb-team priority::medium resolution::fixed severity::normal status::closed tbb-8.0-issues tbb-8.0.1-can tbb-regression type::defect labels

https://bugzilla.mozilla.org/show_bug.cgi?id=1446472

Closed #27598 (moved) as duplicate.

Trac:
Cc: N/A to semmyru

Marking for 8.0.1 can.

Trac:
Keywords: N/A deleted, tbb-8.0.1-can added

Trac:
Keywords: N/A deleted, GeorgKoppen201809 added

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.

Trac:
Keywords: N/A deleted, TorBrowserTeam201809R added
Status: new to needs_review

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.

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.

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)

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 ).

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).

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!

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).

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

closed

mentioned in issue #27598 (moved)

mentioned in issue #27599 (closed)

mentioned in issue #29028 (moved)

moved to tpo/applications/tor-browser#27543 (closed)

mentioned in issue tpo/applications/tor-browser#29028 (closed)