If I get a notification from a page that is in a container tab, and that notification has a URL, clicking on the URL results in a new "No Container" tab opening with that URL. Instead of this, I would have expected that clicking on the URL opens the new tab in the same container as the tab that gave me the notification, just like clicking on a URL in that tab would. My particular steps to reproduce involved slack: * I run multiple slack instances, one of which (the Mozilla one) is in a "Work" container in which I'm logged in to my Mozilla google account rather than my personal one * the notification was from somebody messaging me a URL in a direct message in slack * if I click on the notification, Firefox opens the URL in a new "No Container" tab, whereas if I'd been in the slack tab in the first place looking at my direct message, and clicked on the URL, it would have opened in the "Work" container. It's possible there are other factors involved (e.g., running multiple slacks, only some of which are in containers), since I didn't try reproducing this starting from a clean profile. I'm running nightly on Linux, and using GNOME (the default desktop) on Ubuntu 17.10; I saw this in the 20180306100123 nightly (though I just updated to the next one).

I bet there's currently no mechanism for passing originAttributes with notifications, but you're making an eminently sensible assumption about how it's supposed to work. Otherwise the notifications could give you links that _won't_ work in the wrong container because you're not logged in to that site. Tanvi: what priority should we assign to container bugs? Can Private Browsing use notifications? It would break privacy guarantees/assumptions if those notification links opened up in a non-private window.

BTW, it might be more interesting if service workers and push notifications are involved. I'm not sure how service workers interact with containers.

Service workers are based on full principals which include origin attributes. You can verify this works with containers by: 1. Open a container tab. 2. Navigate container tab to https://gauntface.github.io/simple-push-demo/ 3. Toggle "Enable push notifications" 4. Accept permission 5. Click "send a push via xhr" 6. When the notification appears click it 7. Observe that a new container tab appears for https://developers.google.com/web/fundamentals/ My guess is that the notification is not doing whatever magic docshell does for link navigation.

David, are you using native or xul notifications?

Also, is it really an embedded link in the notification content or is it clicking a notification such that it fires a notificationclick event?

I'm guessing native, since the notification shows up in GNOME's system tray at the top of the screen.

Yes, perhaps the permission should be stored with an Origin Attribute for containers, and then the notification could propagate that attribute into the notification links. Previously, we didn't compartmentalize permissions per Container (they were global). It is probably time to rethink that. We can keep this as a P3 bug, but there are currently no resources on platform Containers bugs/enhancements. There might be an easy fix (that doesn't involve changing permissions) in the notification permission code itself where they can check what the currently active tab is and open the link in that type of container tab. Would that help? Or not, since notifications come up even when you are operating in a different context?