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)
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.
Comment 1•10 years ago
|
||
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.
Blocks: dialer-most-wanted
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
Reporter | ||
Comment 2•10 years ago
|
||
(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.
Reporter | ||
Updated•10 years ago
|
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.
Description
•