Desktop Notifications in Fennec require user action before any notification

RESOLVED FIXED

Status

RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: paul, Assigned: dougt)

Tracking

Trunk
ARM
Android

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
Calling notification.show() brings the "foo.com wants to use notifications. Allow - Don't allow" prompt every time.

A "Always allow" option should be added and the prompt should be shown on createNotification(), not on show().
(Assignee)

Updated

8 years ago
Assignee: nobody → doug.turner
We currently use the same mechanism that geo-location uses. After answering "allow" 5 times, we never ask again for that domain.
(Assignee)

Comment 2

8 years ago
i was mostly concerned about the "the prompt should be shown on createNotification(), not on show()."

not sure if I agree, but i will discuss with other implementers.  paul, any reason why you do not like the permission prompt on show()?
(Reporter)

Comment 3

8 years ago
The notification mechanism exists to attract the attention of the user, even if the browser is in the background.

With current behavior, the notification is only shown if the user is in front of the browser.

I think it would be better if:
* the user load a web page
* web page asks for the permission to show notification (on createNotifaction or on via another dedicated request)
* notification happens later in the future
(Assignee)

Comment 4

8 years ago
yeah, i think you are right.
(Assignee)

Comment 5

8 years ago
oh, i should point out that we have been discussing a permission api such that you can ask the user at any point for a set of permissions.  For example, something like:

navigator.requestPermissions("geolocation, desktop-notifications", callback())

This would also address the problem, but i will think you are right.
(Assignee)

Comment 6

8 years ago
s/will/still
(Assignee)

Comment 7

8 years ago
Created attachment 502571 [details] [diff] [review]
patch v.1
Attachment #502571 - Flags: review?(jst)
(Assignee)

Updated

8 years ago
tracking-fennec: --- → ?
(Assignee)

Updated

8 years ago
Attachment #502571 - Flags: review?(jst) → review?(Olli.Pettay)
tracking-fennec: ? → 2.0+

Comment 8

8 years ago
Could you explain the behavior the patch gives.
(Assignee)

Comment 9

8 years ago
yes.  the patch will change the behavior of prompting when .show() is called to when createNotification() is called.  This will allow sites to request permission prior to the show().
What happens if one does createNotification().show() ?
(Assignee)

Comment 11

8 years ago
we remember that show() was called, and when the notification is approved, we post a desktop notification.  Is that what you are asking?
Comment on attachment 502571 [details] [diff] [review]
patch v.1


> 
> void
>+nsDOMDesktopNotification::SetAllow(PRBool aAllow)
>+{
>+  mAllow = aAllow;
>+
>+  // if we have called Show() already, lets go ahead and post a notification
>+  if (mShowHasBeenCalled)
>+    PostDesktopNotification();
>+}
>+

Why do you call PostDesktopNotification() even is aAllow is false?
(Assignee)

Comment 13

8 years ago
as an exercise for the reviewer! :D
Comment on attachment 502571 [details] [diff] [review]
patch v.1

Ok, fix that :)

I wish there were some tests...
Attachment #502571 - Flags: review?(Olli.Pettay) → review+
(Assignee)

Comment 15

8 years ago
http://hg.mozilla.org/mozilla-central/rev/f8b39d7c6fff
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED

Comment 16

7 years ago
Can you provide some steps to reproduce so that i could verify this bug ?
Is it http://vingtetun.org/todo/ a proper website to verify this bug? If no, could you suggest me one please?
You need to log in before you can comment on or make changes to this bug.