browser notifications are not working anymore with Tor Browser 8

With Tor Browser 8 it seems we broke some browser notification mechanism for macOS as users on our blog report (e.g. https://blog.torproject.org/comment/276960#comment-276960).

added TorBrowserTeam201909R actualpoints::0.5 component::applications/tor browser owner::tbb-team points::0.5 priority::high resolution::fixed severity::normal status::closed tbb-8.0-issues tbb-8.0.1-can tbb-9.0-must-alpha tbb-regression type::defect labels

Marking for 8.0.1 can.

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

Kathy and I did some triage of this ticket because we thought it might be a macOS-only bug, but that is probably not true. It seems to be related to first party isolation of permissions. Using the following page for testing, notifications started to work after I changed privacy.firstparty.isolate to false: https://developer.mozilla.org/en-US/docs/Web/API/notification

On that page, grant permission for notifications when prompted and then click the "Notify me!" button.

Arthur, any ideas?

We got a user on #tor today reporting something similar on Linux which has probably the same underlying issue:

1. start Tor Browser
2. go to a website that offers web push notifications, e.g. ProtonMail https://protonirockerxow.onion, and log in
3. after successfully logging in, the Tor Browser asks "Will you allow protonirockerxow.onion to send notifications", click "Allow Notifications".

Expected result: every time I receive an email, I should get a notification (via libnotify or something like this) that looks just like any other KDE desktop notification.

Instead of this expected result, I get no notification at all.

Arthur, can you pick that up? I think it could be relevant to upstreaming the permissions patch you are working on.

Trac:
Cc: N/A to arthuredelstein

Trac:
Keywords: N/A deleted, TorBrowserTeam201810 added

I confirm that, after changing privacy.firstparty.isolate to false, notifications work again on Linux/KDE.

Trac:
Username: gok

Trac:
Username: gok
Cc: arthuredelstein to arthuredelstein, gok+tortrac@posteo.net

This probably seems related to the permissions patch because I don't have any problem with it on Nightly with FPI enabled.

I just tested notifications with TBB 8.5a4 and First Party Isolation enabled, and notifications did not work. I don't know how different TBB alpha and TBB nightly currently are though, so I don't know if this bit of information helps.

Trac:
Username: gok

Replying to mcs: On Windows 10:

0:26:44.707 [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIContentPermissionRequest.principal]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: jar:file:///C:/Tor%20Browser/Browser/browser/omni.ja!/components/nsBrowserGlue.js :: prompt :: line 3000"  data: no] (unknown)
	prompt jar:file:///C:/Tor%20Browser/Browser/browser/omni.ja!/components/nsBrowserGlue.js:3000:1
0:26:44.707 NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIContentPermissionRequest.cancel] nsBrowserGlue.js:3024

Trac:
Username: nsIContentPermissionRequest
Summary: growl a-like browser notifications are not working anymore on macOS with Tor Browser 8 to browser notifications are not working anymore with Tor Browser 8

Moving our tickets to November.

Trac:
Keywords: TorBrowserTeam201810 deleted, TorBrowserTeam201811 added

Trac:
Priority: Medium to High

Moving our tickets to December.

Trac:
Keywords: TorBrowserTeam201811 deleted, TorBrowserTeam201812 added

Moving tickets to Jan 2019.

Trac:
Keywords: TorBrowserTeam201812 deleted, TorBrowserTeam201901 added

https://bugzilla.mozilla.org/show_bug.cgi?id=1330467 got fixed recently. Thus, we'll get this latest with the switch to Firefox 68 ESR.

Trac:
Keywords: N/A deleted, ff68-esr-will-have added

Got backed out.

Trac:
Keywords: ff68-esr-will-have deleted, N/A added

Using this for backporting the patch in 1330467.

Trac:
Keywords: TorBrowserTeam201901 deleted, TorBrowserTeam201908, tbb-9.0-must-alpha added

We keep this on our radar for two reasons, even though we backported the fixes for 1330467:

1. There are follow-up bug fixes that we should backport in case we keep the patch series
2. It's not clear yet that the permission isolation works with disabling Enhanced Tracking Protection, which we want.

Trac:
Cc: arthuredelstein, gok+tortrac@posteo.net to arthuredelstein, gok+tortrac@posteo.net, acat

Moving must-alpha tickets to September.

Trac:
Keywords: TorBrowserTeam201908 deleted, TorBrowserTeam201909 added

Trac:
Points: N/A to 0.5

Replying to gk:

We keep this on our radar for two reasons, even though we backported the fixes for 1330467:

1. There are follow-up bug fixes that we should backport in case we keep the patch series
2. It's not clear yet that the permission isolation works with disabling Enhanced Tracking Protection, which we want.

I think we are good with respect to 2) as we actually don't disable it but just the UI while setting it to block third party cookies as we are doing right now in the stable series. Which leaves 1).

Unless I'm missing some, these are the fixes we would have to backport:

• Bug 1568521 - Tracking protection doorhanger's Enable/Disable states don't work

  • https://github.com/mozilla/gecko-dev/commit/4f11cdabb32cf1de9cd6ee871ec31f6d8cab660c

• Bug 1557729 - google calendar loses notification permission every time it's loaded

  • https://github.com/mozilla/gecko-dev/commit/52d5f250f15152d0672a30c5c2ef9c6f67ed38ed

• Bug 1572240 - ContentBlockingAllowList._basePrincipalForAntiTrackingCommon is a bit wasteful

  • https://github.com/mozilla/gecko-dev/commit/7b2ff7275b4484a9bab1d4bd4d0d4c1da513b031
  • https://github.com/mozilla/gecko-dev/commit/e06a6e7ca6873165785927fd3c6e29a0d3e5aac2
  • https://github.com/mozilla/gecko-dev/commit/575c480fc556dc5614a9291dd8fb37928d21a316
  • https://github.com/mozilla/gecko-dev/commit/68aa0ff3f4c1e2048ef078714ad57b3ad5a75191
  • https://github.com/mozilla/gecko-dev/commit/05feeeb79be579eb1c651aba060ed783e12470d3
  • https://github.com/mozilla/gecko-dev/commit/c771ae8334e2f691decbcc95526b64e521c11339

The first two are simple fixes, but the third one is not so easy to backport. As it was mentioned on IRC, the patch writer thinks this is risky to backport (https://bugzilla.mozilla.org/show_bug.cgi?id=1560623#c9). I took a quick look, and the patch as is relies on this other patch https://bugzilla.mozilla.org/show_bug.cgi?id=1510569 to update aContentBlockingAllowListPrincipal: https://searchfox.org/mozilla-central/rev/7531325c8660cfa61bf71725f83501028178cbb9/dom/interfaces/base/nsIBrowser.idl#160. I assume it should not be difficult to adapt it to use the old JSM code that is still present in esr68, but probably not a straightforward backport either.

So, given that we are hiding/disabling content blocking for now (and in principle are not affected by that regression) should we postpone backporting this patch until we explore/decide enabling content blocking? If yes, perhaps we could update #30939 (moved) so that we remember to backport this.

The first two are backported here: https://github.com/acatarineu/tor-browser/commits/27601.

Trac:
Keywords: TorBrowserTeam201909 deleted, TorBrowserTeam201909R added
Status: new to needs_review

Replying to acat:

[snip]

So, given that we are hiding/disabling content blocking for now (and in principle are not affected by that regression) should we postpone backporting this patch until we explore/decide enabling content blocking? If yes, perhaps we could update #30939 (moved) so that we remember to backport this.

That looks like a good idea. I'll add a note to that bug. I am interested in seeing https://bugzilla.mozilla.org/show_bug.cgi?id=1554805 in 9.0, too. The proposed patches are not really big and are probably straightforward to apply. I'd wait a bit, though, until they have actually landed. I've created #31811 (moved) to keep track of that.

The first two are backported here: https://github.com/acatarineu/tor-browser/commits/27601.

Those look good and I cherry-picked them onto tor-browser-68.1.0esr-9.0-2 (commit c6eb1efb7d3ca6a9b5e19f6ec352ee1b129efbd3 and f970a6e8a14d8f80f15be22fa1ed6b091b4d596b).

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

Trac:
Actualpoints: N/A to 0.5

closed

changed time estimate to 4h

added 4h of time spent

mentioned in issue #30429 (moved)

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