996384 - WebappsApplication#clearBrowserData should not clear app's alarms from mozAlarms

Status: VERIFIED FIXED

(Core Graveyard :: DOM: Apps, defect)

Description

[Gareth Aye [:gaye] (back from PTO)]

Steps to reproduce:

1. Launch an app.
2. Add an alarm to the system alarms database.
3. Note that you have an alarm in the alarms database.
4. Call clearBrowserData() on the app retrieved from mozApps.getSelf().
5. Note that you have no alarms in the alarms database.

Expected behavior:

clearBrowserData() does not delete my app's alarms from the alarms store.

Comment 1

[Gareth Aye [:gaye] (back from PTO)]

Nominating as a 1.3 blocker since this breaks Google periodic sync in an interesting but nonetheless undesirable way. If this can't be solved in the platform, we can hack around it in calendar in theory, but why make our application code worse when we can instead make the platform better :)?

Comment 2

[Preeti Raghunath(:Preeti)]

Fabrice

Your input is needed on method of fix of the bug. Technical weigh in needed here

Comment 3

[[:fabrice] Fabrice Desré]

Attachment: webapps-clear.patch

We were also making the same mistake in the PushService code, so I wrapped both fixes in this patch.

Comment 4

[Nikhil Marathe [:nsm] (No longer reading bugmail, please needinfo?)]

Is there a 'superior' call to clearBrowserData() that will indeed delete push and alarms? They seem to be 'private data' to me, especially since alarms can have a 'data' attribute.

Comment 5

[Nikhil Marathe [:nsm] (No longer reading bugmail, please needinfo?)]

(In reply to Nikhil Marathe [:nsm] (needinfo? please) from comment #4)
> Is there a 'superior' call to clearBrowserData() that will indeed delete
> push and alarms? They seem to be 'private data' to me, especially since
> alarms can have a 'data' attribute.

Ah sorry! I misunderstood what this is for.

Comment 6

[[:fabrice] Fabrice Desré]

https://hg.mozilla.org/integration/b2g-inbound/rev/9f9528ccd44b

Comment 7

[Gareth Aye [:gaye] (back from PTO)]

Resolved fixed?

Comment 8

[[:fabrice] Fabrice Desré]

(In reply to Gareth Aye [:gaye] from comment #7)
> Resolved fixed?

Not until it's on m-c

Comment 9

[Gareth Aye [:gaye] (back from PTO)]

Ok np. Sorry not super familiar with the mozilla-central workflow.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/9f9528ccd44b

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/981efa650de8

Please request approval-mozilla-b2g28 on the patch for v1.3 uplift when you feel it's sufficiently baked.

Comment 14

[Edward Chen[:edchen]]

*** This bug has been marked as a duplicate of bug 989081 ***

Comment 15

[[:fabrice] Fabrice Desré]

Comment on attachment 8407137 [details] [diff] [review]
webapps-clear.patch

NOTE: This flag is now for security issues only. Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): has always been there!
User impact if declined: Data loss (alarms and push notifications)
Testing completed: yes
Risk to taking this patch (and alternatives if risky): no risk
String or UUID changes made by this patch: none

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/c96b0cf6343f