Closed Bug 755402 Opened 12 years ago Closed 7 years ago

Desktop notification callback never gets called after small delay

Categories

(Firefox OS Graveyard :: General, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: etienne, Assigned: wchen)

Details

(Whiteboard: [WebAPI:P0] [perf-reviewed])

Attachments

(1 file)

Attached file Test file
Even when attaching the callback function to a window kept open.

If we don't (really) hurry to send the desktop-notification-click/close mozContentEvent the callback never gets called.

So looks like a garbage collection issue.
Blocking. Who's the right person to work on this?
blocking-basecamp: --- → +
blocking-kilimanjaro: --- → +
I'm gonna take a look.
Assignee: nobody → fabrice
Ok, so I investigated and here are the results :

When you create the notification, we instanciate an nsDOMDesktopNotification object in c++. This object holds a reference to the callbacks.

If you don't keep the notification object in scope in JS, it is garbage collected, and we disconnect the callbacks here : http://mxr.mozilla.org/mozilla-central/source/dom/src/notification/nsDesktopNotification.cpp#125 (relevant code also at http://mxr.mozilla.org/mozilla-central/source/dom/src/notification/nsDesktopNotification.h#168)

It looks like this is what's happening there, so I'm not sure if the bug is in gaia or not.
I will do some more testing a keep this bug updated.
Doug do you know if that an expected behavior or not?
Major bug.

the nsIAlertsService holds a reference to the nsDesktopNotification via a nsIObserver.  This is so that when the user clicks on the dialog, we can get back to content and call the onclick handler.


* Is the gaia implementation of the nsIAlertService losing that reference?
* Does this work on Android?
(In reply to Doug Turner (:dougt) from comment #6)
> Major bug.
> 
> the nsIAlertsService holds a reference to the nsDesktopNotification via a
> nsIObserver.  This is so that when the user clicks on the dialog, we can get
> back to content and call the onclick handler.
> 
> 
> * Is the gaia implementation of the nsIAlertService losing that reference?

Looking at the code I would say not:
http://mxr.mozilla.org/mozilla-central/source/b2g/components/AlertsService.js
http://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.js#406

> * Does this work on Android?

Dunno.
is "alertfinished" being fired?
(In reply to Vivien Nicolas (:vingtetun) from comment #7)
> (In reply to Doug Turner (:dougt) from comment #6)
> > * Does this work on Android?
> 
> Dunno.

Notification works on release fennec native.
fwiw, I just tested on fennec native (current nightly) and the bug happens there also.
Priority: -- → P1
FYI we're currently working around this bug by keeping a reference on the mozNotification objects.

https://github.com/mozilla-b2g/gaia/blob/master/apps/dialer/js/notification_helper.js#L8
Assignee: fabrice → doug.turner
I do not think that this is a blocker.

1) we have a work around for apps
2) for the browser, web content isn't really using desktop notifications
3) we are working on getting rid of this web api in favor of the w3c version (http://www.w3.org/TR/notifications/)
Whiteboard: [WebAPI:P0]
blocking-basecamp: + → ?
blocking-kilimanjaro: + → ?
Based on comment #12, not a blocker.
blocking-basecamp: ? → -
william, can you see if this is still an issue after bug 782211 is fixed?
Assignee: doug.turner → wchen
blocking-basecamp: - → ---
blocking-kilimanjaro: ? → ---
Whiteboard: [WebAPI:P0] → [WebAPI:P0] [perf-reviewed]
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: