Closed Bug 996384 Opened 6 years ago Closed 6 years ago

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


(Core Graveyard :: DOM: Apps, defect)

Not set


(blocking-b2g:1.3+, firefox29 wontfix, firefox30 fixed, firefox31 fixed, b2g-v1.3 fixed, b2g-v1.3T fixed, b2g-v1.4 fixed, b2g-v2.0 fixed)

blocking-b2g 1.3+
Tracking Status
firefox29 --- wontfix
firefox30 --- fixed
firefox31 --- fixed
b2g-v1.3 --- fixed
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed


(Reporter: gaye, Assigned: fabrice)




(1 file)

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.
Blocks: 995827
blocking-b2g: --- → 1.3?
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 :)?

Your input is needed on method of fix of the bug. Technical weigh in needed here
Flags: needinfo?(fabrice)
We were also making the same mistake in the PushService code, so I wrapped both fixes in this patch.
Assignee: nobody → fabrice
Attachment #8407137 - Flags: review?(nsm.nikhil)
Attachment #8407137 - Flags: review?(gene.lian)
Flags: needinfo?(fabrice)
Attachment #8407137 - Flags: review?(gene.lian) → review+
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.
(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.
blocking-b2g: 1.3? → 1.3+
Resolved fixed?
(In reply to Gareth Aye [:gaye] from comment #7)
> Resolved fixed?

Not until it's on m-c
Ok np. Sorry not super familiar with the mozilla-central workflow.
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
Duplicate of this bug: 989081
No longer blocks: 995827
Duplicate of this bug: 995827

Please request approval-mozilla-b2g28 on the patch for v1.3 uplift when you feel it's sufficiently baked.
*** This bug has been marked as a duplicate of bug 989081 ***
Comment on attachment 8407137 [details] [diff] [review]

NOTE: This flag is now for security issues only. Please see 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
Attachment #8407137 - Flags: approval-mozilla-b2g28?
Attachment #8407137 - Flags: approval-mozilla-b2g28? → approval-mozilla-b2g28+
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.