Closed Bug 1071653 Opened 10 years ago Closed 10 years ago

Do not remove calls from the call log UI if they weren't properly deleted

Categories

(Firefox OS Graveyard :: Gaia::Dialer, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 892476

People

(Reporter: gsvelto, Unassigned)

References

Details

+++ This bug was initially created as a clone of Bug #1029142 +++ Currently we remove calls from the UI even when their deletions fails and we do so without checking if the associated transaction has succeeded so we can have both situations where we've not removed some calls (bug 1029142) yet we remove them from the UI; and cases where the entire transaction can fail yet we'd happily chug along as if everything went fine.
Unfortunately, doing this would likely make the UI feel sluggish. Before going forward, we should test how slow it is to verify that the transaction completes before updating the UI. But if it does indeed slow it down significantly, I have a proposal to mitigate this: 1. Store the list of UI nodes to be deleted into an array. 2. Dispatch the transaction to delete the calls. 3. Remove the UI nodes from the call log. 4. Transaction: a. Succeeds: do nothing. b. Fails: Restore the UI nodes from the array. Display an error message. The case that the deletion fails should ideally be exceedingly rare. So it makes more sense to me to optimize for the common case. Though this would involve more work and more points of failure. A similar discussion took place in bug 1001467 for the SMS app, though it was mostly focused on performance.
Summary: Do not remove calls from the UI if they weren't properly deleted → Do not remove calls from the call log UI if they weren't properly deleted
(In reply to Doug Sherk (:drs) from comment #1) > The case that the deletion fails should ideally be exceedingly rare. So it > makes more sense to me to optimize for the common case. Though this would > involve more work and more points of failure. +1, let's make the common case fast and the rare case correct - we don't need the latter to be fast too, just non-confusing like it currently is.
See Also: → 860245
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.