Closed Bug 838119 Opened 11 years ago Closed 11 years ago

[DIALER][CALL LOG] Select all option is not working fine if the device is locked while the user is in the edit mode

Categories

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

x86_64
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g18+ fixed)

RESOLVED FIXED
Tracking Status
b2g18 + fixed

People

(Reporter: rafael.marquez, Assigned: gtorodelvalle)

References

Details

Attachments

(1 file)

* Procedure
1. Having multiple call records in the call lag
2. Open edit mode
3. Press the "Select All"
4. Lock your phone
5. Unlock the phone

* Expected result
All records continue SELECTED and the "Select All" button appears active.

* Current result
The button "Select All" appears active, but the records are not SELECTED.
blocking-b2g: --- → tef?
tracking-b2g18: --- → ?
tracking-b2g18: ? → ---
blocking-b2g: tef? → ---
tracking-b2g18: --- → ?
Does this mean that the user just hits select all again and is back to having all records selected?  Is there something unusual about the 'appears active'?
The unusual is "The button "Select All" appears active, but the records are not SELECTED."
If the records appears not selected, the Select all button should be deactivated. This is a MISMATCH
I'm CCing some people who've worked on the dialer code recently.
BTW, I just noticed that the status of the buttons in the footer is not correct either. I mean the "Deselect all" appears enabled and the "Select all" appears disabled after opening the Communications app. Fixing that too so that when opening the Communications app after closing it via the "Home" button, all the entries appear as deselected and the status of the rest of active components is coherent.
Attached file Associated PR.
Attachment #721713 - Flags: review?(fbsc)
Could you check if this error is still there after latest changes in Master???
One problem found was that when 'visibility' changes, we were re-rendering the whole list of call-logs. That's why we had a weird behaviour there. However, this was fixed in the performance bug, so probably it's working as expected now... That's why Im asking to check again in Master
Sure ;-) Re-checked and working fine for me :-) Currently discussing with Mari Ángeles if the current behavior is the desired one. Thanks!
Setting Fernando Campo as the reviewer of this patch since Borja is focused on the SMS and MMS stuff ;-)
Attachment #721713 - Flags: review?(fbsc) → review?(fernando.campo)
BTW, the agreed behavior is the following: if the user has any entry as selected in edit mode and clicks on the "Home" button, this selection is kept whenever the Comms app is reshown again, unless new calls get to the phone since these calls may make the previous selection invalid.
Comment on attachment 721713 [details]
Associated PR.

Low risk changes disabling buttons depending on the selection on edit mode, cool ;)
Attachment #721713 - Flags: review?(fernando.campo) → review+
Assignee: nobody → gtorodelvalle
This issue also happens in v1.0.1 and v1-train.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment on attachment 721713 [details]
Associated PR.

NOTE: 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 #): 
User impact if declined: 
Testing completed: 
Risk to taking this patch (and alternatives if risky):
String or UUID changes made by this patch:
Attachment #721713 - Flags: approval-gaia-v1?
Attachment #721713 - Flags: approval-gaia-v1?
Comment on attachment 721713 [details]
Associated PR.

NOTE: 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 #): The status of the buttons in the Call Log edit mode is not restored after re-rendering
User impact if declined: Illogical information
Testing completed: Tested in the device
Risk to taking this patch (and alternatives if risky): Low risk
String or UUID changes made by this patch: None
Additional information: 1 changed file with 22 additions and 0 deletions.
Attachment #721713 - Flags: approval-gaia-v1?
Comment on attachment 721713 [details]
Associated PR.

Missed the cutoff by a few days for tracked bugs and is low risk - approving.
Attachment #721713 - Flags: approval-gaia-v1? → approval-gaia-v1+
Uplifted commit 038974f2724feebb99d0bff21885c097a0f2bd42 as:
v1-train: 901fce400ac9c482d77431ad33db4ac5fb811050
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: