GNOME Bugzilla – Bug 765321
Allowing notification for a website is not remembered across sessions
Last modified: 2016-04-29 16:28:26 UTC
Steps to reproduce: 1. Go to any website which uses desktop notifications. For example, go to http://ttsvetko.github.io/HTML5-Desktop-Notifications/ 2. Allow the website to show notifications. 3. Close Epiphany. 4. Launch Epiphany again and open the same site again. Actual outcome: * The website shows again that the user has not been asked whether notifications are allowed. Expected outcome: * Epiphany remembers that notifications have been already allowed for the website, and lets the website know the user preference. This is an issue that does not prevent any website from working, but it is annoying for the user to have to allow (or disallow) notifications for a certain website. While in everyday browsing this is not much of an issue, having a web application in an “application mode” instance of Epiphany this gets annoying very quickly, precisely because the kind of web applications that an user is likely to use in app mode are those which use notifications (mainly instantant messagging apps like Matrix/Vector, Slack, Telegram... but also others like Facebook can use desktop notifications). I suspect that the main issue here is that, if user preferences are remembered, probably it would be good to also provide an UI to reset per-website preferences. One first step could be to remember the desktop notifications preferences while in web application mode without adding any new UI, and then adding the per-website preferences UI later on. WDYT?
*** This bug has been marked as a duplicate of bug 748339 ***
(In reply to Adrian Perez from comment #0) > One first step could be to > remember the desktop notifications preferences while in web > application mode without adding any new UI This should already be the case as of 3.20.1, do you have that update yet?
(In reply to Michael Catanzaro from comment #2) > (In reply to Adrian Perez from comment #0) > > One first step could be to > > remember the desktop notifications preferences while in web > > application mode without adding any new UI > > This should already be the case as of 3.20.1, do you have that update yet? Yes, I am Epiphany 3.20.1 with WebKitGTK+ 2.12.1 from the latest Arch Linux packages, yet the allowed/denied notifications don't seem to be remembered.
(In reply to Adrian Perez from comment #3) > (In reply to Michael Catanzaro from comment #2) > > (In reply to Adrian Perez from comment #0) > > > One first step could be to > > > remember the desktop notifications preferences while in web > > > application mode without adding any new UI > > > > This should already be the case as of 3.20.1, do you have that update yet? > > Yes, I am Epiphany 3.20.1 with WebKitGTK+ 2.12.1 from the latest > Arch Linux packages, yet the allowed/denied notifications don't > seem to be remembered. For the sake of completeness, I have tried using a fresh user profile, running Epiphany with the following command from a terminal: % epiphany --profile=/tmp/notifications-test …but the allowed/denied notifications are still not remembered. Is there something else I can easily try to help debug this? FWIW bug #748339 —which this one is supposed to be duplicate of— is still in “NEW” state. Could it be that the patch attached to it has not ever been applied to the repository?
(In reply to Adrian Perez from comment #4) > FWIW bug #748339 —which this one is supposed to be duplicate of— is still > in “NEW” state. Could it be that the patch attached to it has not ever > been applied to the repository? Correct, the bug is not fixed yet. I thought it was fixed only for the particular case of web apps. But it turns out I got it mixed up with bug #672573. Anyway, web apps should never request notifications permissions, they should be granted automatically.
OK, two duplicate bugs here: * This is bug #748339 (open) in the case we are not talking about web apps. * This is bug #759176 (resolved fixed) in the case of web apps. If you think bug #759176 is still not fixed, please do reopen that one, thanks! *** This bug has been marked as a duplicate of bug 748339 ***