Evan Tseng [:evanxd] Reporter
	Description • 11 years ago

We would like to save the notification items after reboot the device. But on Gecko side currently, the notification items was deleted after reboot device.

STP:
1. cherry-pick the patch: https://github.com/evanxd/gaia/commit/badc9fc472996128bd461260bc8413ba52a9f949 (now you could save the notification after reboot the device)
2. Make phone call to the device for adding a notification item.
3. Reboot the device. (Dialer App didn't run in the background)
4. Click the notification item.

Expected:
The dialer was triggered.

Currently:
Nothing happen. And the function registered in navigator.mozSetMessageHandler('notification', function(){}) wasn't trigger.

	Julien Wajsberg [:julienw]
	Comment 1 • 11 years ago

blocks a leo+.

Triagers, please value if it's worth it for leo, this sounds like a new feature to me...

	Alex Keybl [:akeybl]
	Comment 2 • 11 years ago

Bug 874364 is QE3, so this should be too. Over to Lucas to reassign for Gecko.

	Julien Wajsberg [:julienw]
	Comment 3 • 11 years ago

Bug 874364 is not leo+ anymore, renominating then.

(+ this would probably be a b2g18-only patch since the notification api was completely redone in central since then).

	Wayne Chang [:wchang]
	Comment 4 • 11 years ago

Removing leo+ and noming for koi? to align with 874364 comment 14

	bhavana bajaj [:bajaj]
	Comment 5 • 11 years ago

needinfo mike/gregor to understand if this is covered in https://bugzilla.mozilla.org/show_bug.cgi?id=899574 ?

	Michael Henretty [:mikehenrty][:mhenretty] Assignee
	Comment 6 • 11 years ago

Bhavana,

I am confused about this bug report. For me, when I have a missed call notification and I reboot my device, the entire notification goes away, meaning there is nothing to click on to try and generate this mozContentEvent. Perhaps I am misunderstanding the steps to repro?

In any case, bug 889547 is definitely needed to fix this. But we will still need bug 874364 so that the system app can re-fetch and display these notifications on reboot. Once that happens, the mozContentEvent should just work.

	Evan Tseng [:evanxd] Reporter
	Comment 7 • 11 years ago

Hi Michael,

We could cherry-pick the patch https://github.com/evanxd/gaia/commit/badc9fc472996128bd461260bc8413ba52a9f949 to save the notifications.

And you check the Description.

Thanks. :)

	Evan Tseng [:evanxd] Reporter
	Comment 8 • 11 years ago

The Description is in https://bugzilla.mozilla.org/show_bug.cgi?id=881159#c0.

	Michael Henretty [:mikehenrty][:mhenretty] Assignee
	Comment 9 • 11 years ago

(In reply to Evan Tseng [:evanxd] from comment #7)
> We could cherry-pick the patch
> https://github.com/evanxd/gaia/commit/
> badc9fc472996128bd461260bc8413ba52a9f949 to save the notifications.

Got it. So, we will need both bug 899574 and bug 874364, plus a patch similar to this one above in gaia (except using Notification.get) to make this work. The first two bugs should be done later this week, then we can move forward with the system app patch.

	Preeti Raghunath(:Preeti)
	Comment 10 • 11 years ago

koi+

	Julien Wajsberg [:julienw]
	Comment 11 • 11 years ago

Is this really a blocker for the release ? It worked like that in 1.1, therefore it's not a regression. To be fair I'm a little worried to uplift such invasive and (imo) non-blocker patches in 1.2 :/

	Jason Smith [:jsmith]
	Comment 12 • 11 years ago

(In reply to Julien Wajsberg [:julienw] from comment #11)
> Is this really a blocker for the release ? It worked like that in 1.1,
> therefore it's not a regression. To be fair I'm a little worried to uplift
> such invasive and (imo) non-blocker patches in 1.2 :/

Shouldn't be a blocker for 1.2. We were thinking of making this a target objective for 1.3, so sending this to 1.3?

	Michael Henretty [:mikehenrty][:mhenretty] Assignee
	Comment 13 • 10 years ago

The work for this was done in bug 967475.