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

Status: VERIFIED FIXED

(Firefox :: Site Identity, defect, P1)

Description

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: Screenshot of notification prompt

I initially thought this was related to bug 1549912, but it's still happening to me. (It might even be a newer regression than that was, but I think it regressed around the same time.

For me, Google Calendar no longer retains its notification permission. I have Google Calendar loaded in two pinned tabs -- one in "No Container" (with my personal google account) and one in the "Work" container (with my Mozilla Google account). Both of them lose the notifications permission each time they're reloaded. In other words, every time I go to the URL bar and hit enter to reload the page, or every time I restart the browser, there's a notification permission icon in the URL bar that wants to make a notifications permission prompt (see screenshot).

If I click Allow... I'm not sure it even does anything. I don't think I've seen a proper browser notification from Google Calendar for weeks or months (though I might be wrong), even though I've hit the "Allow" button many times once I realized that it wasn't retaining the permission. It's giving me reminders for events using only alert dialogs (which I don't see, since I haven't given it permission for its alerts to switch me to the tab).

I'm running nightly channel on 64-bit Linux (Ubuntu 18.04 LTS).

Comment 1

[Johann Hofmann [:johannh]]

Do you have FPI on?

Is there any chance you can track this down with mozregression?

What's the result of running Services.perms.testExactPermissionFromPrincipal(gBrowser.contentPrincipal, "desktop-notification") in your browser console on that page?

Thanks!

Comment 2

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

(In reply to Johann Hofmann [:johannh] from comment #1)

Do you have FPI on?

What's FPI?

Is there any chance you can track this down with mozregression?

Not this week, but maybe next.

What's the result of running Services.perms.testExactPermissionFromPrincipal(gBrowser.contentPrincipal, "desktop-notification") in your browser console on that page?

Where exactly? This doesn't work in the devtools console (since Services isn't accessible), and the browser console doesn't have a place to input script and also doesn't seem associated with the page.

Comment 3

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

(In reply to David Baron :dbaron: 🇨🇦 ⌚UTC-4 (busy June 4-7) from comment #2)

What's the result of running Services.perms.testExactPermissionFromPrincipal(gBrowser.contentPrincipal, "desktop-notification") in your browser console on that page?

Where exactly? This doesn't work in the devtools console (since Services isn't accessible), and the browser console doesn't have a place to input script and also doesn't seem associated with the page.

It turns out I needed to go to Devtools settings -> "Enable browser-chrome and addons debugging toolboxes" in order to get the input line in the browser console back. (I remember it being there in the past, and it's what I thought you meant.) Once I did that, I found the result of running that in the browser console is 0. (And I did check it was the right gBrowser, even though it didn't look like it would be.)

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Ah, and yes, I do have First Party Isolation on.

Comment 5

[Johann Hofmann [:johannh]]

Ah, yes, that all makes sense now, this line must have been missed during rebase for bug 1330467:
https://searchfox.org/mozilla-central/rev/153172de0c5bfca31ef861bd8fc0995f44cada6a/browser/modules/PermissionUI.jsm#531

I'll fix it since Gary is on PTO, thanks for catching this.

Comment 6

[(no longer active)]

Note that SitePermissions.set() is used in even more places.

Comment 7

[Johann Hofmann [:johannh]]

Attachment: Bug 1557729 - Use principal for permission post prompts instead of URI. r=xeonchen

Comment 8

[Johann Hofmann [:johannh]]

(In reply to :Ehsan Akhgari from comment #6)

Note that SitePermissions.set() is used in even more places.

Yeah and we should probably track those, but I'd prefer to handle them in different bugs, I think.

Comment 9

[Johann Hofmann [:johannh]]

And my idea for replacing all the test occurrences is bug 1531303 :)

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b4ebf47ce337
Use principal for permission post prompts instead of URI. r=xeonchen

Comment 11

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/b4ebf47ce337

Comment 12

[Cristian Fogel [:cfogel]]

Updating flags based on comment 13.
Can also confirm on WIn_10 that the issue is not present with 69.0b7 and the permissions are kept even after a refresh/restart.