Closed Bug 1017961 Opened 11 years ago Closed 11 years ago

[Flame][v1.4][Contacts]The progress bar is still in loading status when delete the first mobile number in contact edit page.

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: greatwall2686, Unassigned)

Details

(Whiteboard: torch)

Attachments

(1 file)

* Description: The progress bar is still in loading status when delete the first mobile number in contact edit page. Then cancel the edit, the number is still exist. But go into edit page, the number is disappeared.(VID_20140530_105545) * Reproduction steps: 1. Open the contact app 2. Choose a contact which save more than 2 mobile phone 3. Go into the contact edit page 4. Tap the fork button to delete the first mobile phone’s number 5. Update the edit page * Expected result: The first mobile phone’s number delete successfully * Actual result: The progress bar is still in loading status, and the number can’t deleted * Reproduction build:(Buri - Firefox OS V1.4 outside) - Gaia 17b102ee8d9a724b62285547cc5f1c5d30bfb01c - Gecko https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/95be84248033 - BuildID 20140520000201 - Version 30.0 * Reproduction Frequency - 10/10
QA Wanted to check 1.3.
Keywords: qawanted
Summary: [Flame][V1.4][Contacts]The progress bar is still in loading status when delete the first mobile number in contact edit page. → [Flame][v1.4][Contacts]The progress bar is still in loading status when delete the first mobile number in contact edit page.
This issue does NOT occur on the Flame 1.3 Base Image: Environmental Variables: Device: Flame 1.3 Build ID: 20140520094859 Gaia: a73235d23685e9898f40647cebd83b3fcbfd0117 Gecko: b637b0677e15318dcce703f0358b397e09b018af Version: 28.0 (1.3) Firmware Version: v10G-2
Assignee: nobody → ychung
Keywords: qawanted
Can we confirm this on the latest 1.4?
Keywords: qawanted, regression
QA Contact: dgomez
Assignee: ychung → nobody
This issue DOES NOT occur on Flame 1.4 1.4 Environmental Variables: Device: Flame 1.4 Build ID: 20140611000202 Gaia: d1cf95dc5e8b2f52148487291318542f1396608e Gecko: a8bb6b76696b Version: 30.0 (1.4) Firmware Version: v10G-2
Assignee: nobody → ychung
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Assignee: ychung → nobody
Flags: needinfo?(jmitchell)
Joshua - If the bug no longer reproduces on the latest build, you should mark the bug as works for me.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage?][lead-review-]
Flags: needinfo?(jmitchell)
Right you are! I miss-read the issue as written up in 2.0 and not occurring in 1.4 but that is not the case. It is written-up for 1.4 but no longer occurring in the latest 1.4 Marking as works-for-me
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
QA Whiteboard: [QAnalyst-Triage?][lead-review-] → [QAnalyst-Triage+][lead-review-]
Flags: needinfo?(jmitchell)
Resolution: --- → WORKSFORME
QA Whiteboard: [QAnalyst-Triage+][lead-review-] → [QAnalyst-Triage+][lead-review+]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: