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)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: greatwall2686, Unassigned)
Details
(Whiteboard: torch)
Attachments
(1 file)
|
3.68 MB,
application/zip
|
Details |
* 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
| Reporter | ||
Comment 1•11 years ago
|
||
| Reporter | ||
Updated•11 years ago
|
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.
Comment 3•11 years ago
|
||
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
Updated•11 years ago
|
QA Contact: dgomez
Updated•11 years ago
|
Assignee: ychung → nobody
Comment 5•11 years ago
|
||
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
Updated•11 years ago
|
Assignee: ychung → nobody
Updated•11 years ago
|
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
Comment 6•11 years ago
|
||
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)
Comment 7•11 years ago
|
||
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)
Keywords: regression,
regressionwindow-wanted
Resolution: --- → WORKSFORME
Updated•11 years ago
|
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.
Description
•