Closed
Bug 755402
Opened 13 years ago
Closed 8 years ago
Desktop notification callback never gets called after small delay
Categories
(Firefox OS Graveyard :: General, defect, P1)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: etienne, Assigned: wchen)
Details
(Whiteboard: [WebAPI:P0] [perf-reviewed])
Attachments
(1 file)
1.13 KB,
text/html
|
Details |
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.
Comment 1•13 years ago
|
||
Blocking. Who's the right person to work on this?
blocking-basecamp: --- → +
blocking-kilimanjaro: --- → +
Comment 3•13 years ago
|
||
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.
Reporter | ||
Comment 4•13 years ago
|
||
I will do some more testing a keep this bug updated.
Comment 5•13 years ago
|
||
Doug do you know if that an expected behavior or not?
Comment 6•13 years ago
|
||
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?
Comment 7•13 years ago
|
||
(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.
Comment 8•13 years ago
|
||
is "alertfinished" being fired?
Comment 9•13 years ago
|
||
(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.
Comment 10•13 years ago
|
||
fwiw, I just tested on fennec native (current nightly) and the bug happens there also.
Updated•13 years ago
|
Priority: -- → P1
Reporter | ||
Comment 11•13 years ago
|
||
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
Updated•13 years ago
|
Assignee: fabrice → doug.turner
Comment 12•13 years ago
|
||
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/)
Updated•13 years ago
|
Whiteboard: [WebAPI:P0]
Updated•13 years ago
|
blocking-basecamp: + → ?
blocking-kilimanjaro: + → ?
Comment 14•12 years ago
|
||
william, can you see if this is still an issue after bug 782211 is fixed?
Assignee: doug.turner → wchen
Updated•12 years ago
|
blocking-basecamp: - → ---
blocking-kilimanjaro: ? → ---
Whiteboard: [WebAPI:P0] → [WebAPI:P0] [perf-reviewed]
Updated•8 years ago
|
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•