Closed Bug 972091 Opened 10 years ago Closed 10 years ago

[B2G][Contacts] Header bar, search bar and all contacts can be completely missing on the main contacts' view window

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:1.3+, b2g-v1.2 unaffected, b2g-v1.3 verified, b2g-v1.3T fixed, b2g-v1.4 unaffected)

VERIFIED FIXED
1.4 S3 (14mar)
blocking-b2g 1.3+
Tracking Status
b2g-v1.2 --- unaffected
b2g-v1.3 --- verified
b2g-v1.3T --- fixed
b2g-v1.4 --- unaffected

People

(Reporter: KTucker, Assigned: crdlc)

References

Details

(Keywords: regression, Whiteboard: burirun1.3-3, dogfood1.4)

Attachments

(3 files, 1 obsolete file)

Description:
If the user manually creates a contact, logs into Facebook, imports a Gmail contact that has a different first and last name but contains the same phone number as the manual contact and then backs out of the "finding duplicate contacts" window, the header bar, search bar and the contacts themselves will be missing on the main contacts' view.  

Prerequisite: Create a contact on Gmail that has a first and last name and the phone number "123456789".

Repro Steps:
1)  Updated Buri to Build ID: 20140212004003
2)  Tap on the "Contacts" app.
3)  Tap on the "+" to create a new contact.
4)  For first name put "Angie", last name "May" and "123456789" for the phone number.
5)  Tap "Done" to save the contact.
6)  Tap on the "Gear" icon, tap on "Facebook Sync friends" and log into Facebook.
7)  When the list of contacts for Facebook is shown to import, tap on the "X" button to close the "Facebook Friends" window. Do not import any contacts. 
8)  Tap on "Import Contacts" and then tap on "Gmail".
9)  Log into Gmail, select a contact that has the same phone number as the manually created contact but has a different first and last name.
10) Tap on "Update". 
11) Tap the "Back Arrow" to return to "Settings" after importing the Gmail contact and then tap on "Done" to return to the main contacts' window.
12) Tap on the manually created contact "Angie May" and then tap on "Find duplicate contacts". 
13) Tap on the "X" button to close the "Merge duplicates" window and then tap on the "Back Arrow" to return to the main contact's view.

Actual:
The user will observe that the contacts' header, search bar and all contacts will be missing on the main contacts' view.

Expected:
The contacts' main view window appears correctly and shows all the user's contacts, search bar and the header bar. 

Environmental Variables
Device: Buri v 1.3.0 Mozilla RIL
Build ID: 20140212004003
Gecko: https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/ab07e61c2eb0
Gaia: ce17d5eae7b1893ae4397c814b10ae598fcbdb58
Platform Version: 28.0
Firmware Version: v1.2-device.cfg

Notes:
Repro frequency: 100%
Link to failed test case: 
See attached: video clip, logcat

Please note that i have tried to shorten these steps but i can only reproduce the issue following these exact steps.
This issue does not occur on the Buri v 1.3.0 Mozilla RIL

Environmental Variables:
Device: Buri 1.2 MOZ
BuildID: 20140210004002
Gaia: 539a25e1887b902b8b25038c547048e691bd97f6
Gecko: 2673f348598c
Version: 26.0
Firmware Version: v1.2-device.cfg

Following the steps above i could not get the header, search bar or the contacts to disappear on the main contacts' view window.
This needs reduced STR.
QA Contact: sarsenyev
Reduced step to repro:

Prerequisite: Create a contact on Gmail with first, last name and the phone number "123456789".          

1) Create a contact with the same number as Gmail contact (e.i 123456789)
2) Navigate to "Contact Settings" (cogwheel) icon and navigate "Import>From Gmail
3) Sign into Gmail account
4) Select and import the previously created contact with the phone number-"123456789" 
5) Return to the "Contacts" list and select the manually created contact with the same phone number
6) Tap the "Find duplicate contacts"
7) Tap the "X" to close the "Merge duplicates" page 
8)Tap the "<" icon to navigate back to the contact page

Actual Result:
The Contact page appears without header and contacts 

Expected Result:
All information is displayed
Keywords: steps-wanted
So what it sounds like the bug is that if I try to cancel a merge of a local contact with a contact from a third-party service, then I'll get a broken UI in the contacts app. That's seem plausible to happen, given that you might not want to merge a certain set of contacts that are found to be dupes when finding duplicates. Showing a broken UI is also a terrible UX, so I think this hits the category of being a bug we need to fix for 1.3.
blocking-b2g: --- → 1.3?
1.3+ 

David, please review from contacts.
blocking-b2g: 1.3? → 1.3+
Flags: needinfo?(dscravaglieri)
This issue started reproducing on the 01/10/14 1.3 build.

- Works -
Device: Buri v1.3 MOZ RIL
BuildID: 20140109004002
Gaia: 22bc6be5b76cdc6d4e9667ff070979041a20ce2f
Gecko: 2c8f8683bd0d
Version: 28.0a2
Firmware Version: V1.2-device.cfg

- Broken -
Device: Buri v1.3 MOZ RIL
BuildID: 20140110004009
Gaia: c606b129a2d1647c0fc7bfb197555026e9b27f9e
Gecko: c5109884ae3a
Version: 28.0a2
Firmware Version: V1.2-device.cfg
Contacts is primarily owned by TEF, so I'm redirecting the needinfo request to Noemi.
Flags: needinfo?(dscravaglieri) → needinfo?(noef)
(In reply to Jason Smith [:jsmith] from comment #8)
> Contacts is primarily owned by TEF, so I'm redirecting the needinfo request
> to Noemi.

José Manuel will have a look at it.
Assignee: nobody → jmcf
Flags: needinfo?(noef)
the effect reported by this bug will be fixed once bug 959414 lands, as it has the same root cause and the same fix.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
The partial fix for issue https://bugzilla.mozilla.org/show_bug.cgi?id=959414 did not resolve this issue in fact my issue is even easier to reproduce now.  I'm reopening this issue. 

This issue is still occurring on the latest Buri v 1.4.0 Mozilla RIL

Environmental Variables
Device: Buri v 1.4.0 Mozilla RIL
Build ID: 20140220040203
Gecko: https://hg.mozilla.org/mozilla-central/rev/660b62608951
Gaia: 6e71ab4da1b08586ea0c758edb7aa199ee34cd2f
Platform Version: 30.0a1
Firmware Version: v1.2-device.cfg

STR:

1. Tap on the "Contacts" app.
2. Tap on the "Search" field.
3. Tap on "Cancel".
4. If the issue does not occur, repeat steps 2 and 3 until encountering the issue.   

Actual:
The header bar, search bar and the contacts themselves will be missing on the main contacts' view if the user taps on cancel while on the search page for contacts. 

*Screenshot attached.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Whiteboard: burirun1.3-3 → burirun1.3-3, dogfood1.4
I cannot reproduce it with:

Devices Hamachi and Unagi
Gecko   cf974e3
Gaia    6e883bde818d4d53aef7b5b075b4b34267918360 (current v1.3 while I am writing this comment)
Keywords: qawanted
I was able to reproduce this issue following the steps from comment 12 on the latest Buri v 1.3.0 Mozilla RIL

Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140225004004
Gaia: 6e883bde818d4d53aef7b5b075b4b34267918360
Gecko: e597280f9300
Version: 28.0
Firmware Version: V1.2-device.cfg

The header bar, search bar and all contacts were gone after tapping cancel on the search contacts page.
Keywords: qawanted
100% repro for this issue is to factory reset the phone, manually create only one contact, tap on the search bar and then tap on cancel. After adding more contacts, this issue does not reproduce 100%. I was only able to reproduce 1/10 times after adding 9 more contacts.
Whiteboard: burirun1.3-3, dogfood1.4 → burirun1.3-3, dogfood1.4, qawanted
Whiteboard: burirun1.3-3, dogfood1.4, qawanted → burirun1.3-3, dogfood1.4
Let's backup here & get the STR clarified clearly with the reproduction rate.
Keywords: qawanted
Just to clarify, this screenshot [1] has rocketbar so this is not in v1.3

[1] https://bug972091.bugzilla.mozilla.org/attachment.cgi?id=8379250
I've the reproduced the issue:

Today build:

Device  Hamachi
Gecko   764084b
Gaia    8643484

STR:

1. Tap on the "Contacts" app.
2. Create a contact called "Test"
3. Go to contact lits
4. Tap on the "Search" field.
5. Tap on "Cancel".
6. If the issue does not occur, repeat steps 2 and 3 until encountering the issue.

APZ enabled for apps -> it is reproducible
APZ disabled for apps -> it is NOT reproducible

Vivien, Etienne,

Do you have any idea why it is happening? Any suggestion what I could take a look at?
Flags: needinfo?(etienne)
Flags: needinfo?(21)
Attached patch 972091.patch (obsolete) — Splinter Review
Hi mates, it fixes the problem, do you think that it is ok?
Attachment #8382004 - Flags: feedback?(etienne)
Attachment #8382004 - Flags: feedback?(21)
Comment on attachment 8382004 [details] [diff] [review]
972091.patch

So looking at the patch it seems that forcing a repaint solve the issue. Sounds like a gecko issue.

Milan, any chance one of your folks can look at that or should we go with a workaround for the sake of releasing ?
Attachment #8382004 - Flags: feedback?(21)
Flags: needinfo?(etienne) → needinfo?(milan)
Comment on attachment 8382004 [details] [diff] [review]
972091.patch

Wow. Last time I saw this kind of trick was in Berlin I think :)
This should be our last resort, let's bet on a platform fix.
Attachment #8382004 - Flags: feedback?(etienne)
Yep, you're right bug 831391. I just wanted to show that the problem is related to gecko issue :) And if the fix is not feasible in gecko for 1.3, we could use this ugly approach (totally disagree with this kind of workarounds)
For 1.3, take this if it masks the problem and just open another one for 1.4. If we fix it in 1.4, and it's appropriate to uplift, and it's in time for 1.3, then we can back this workaround out and put the real fix in.
Flags: needinfo?(milan)
Keywords: qawanted
Attached file Patch v1 v1.3
Attachment #8382004 - Attachment is obsolete: true
Attachment #8382004 - Flags: review?(jmcf)
Comment on attachment 8382832 [details]
Patch v1 v1.3

r=me but please add a bit more of documentation just in case we need to rely on this if a Gecko fix doesn't come in time
Attachment #8382832 - Flags: review+
Assignee: jmcf → nobody
Added comment on the patch with bug number
Comment on attachment 8382832 [details]
Patch v1 v1.3

See comment 24

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
[User impact] if declined: bad UX
[Testing completed]: yes
[Risk to taking this patch] (and alternatives if risky): close to null
[String changes made]:
Attachment #8382832 - Flags: approval-gaia-v1.3?(fabrice)
Assignee: nobody → crdlc
Target Milestone: --- → 1.4 S2 (28feb)
(In reply to Cristian Rodriguez (:crdlc) from comment #23)
> I just wanted to show that the problem is
> related to gecko issue :) And if the fix is not feasible in gecko for 1.3,
> we could use this ugly approach (totally disagree with this kind of
> workarounds)

Please make sure there is a bug on file for tracking the gecko fix. I didn't see one referenced anywhere in this bug, and it would be bad for us to lose track of this.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #29)
> (In reply to Cristian Rodriguez (:crdlc) from comment #23)
> > I just wanted to show that the problem is
> > related to gecko issue :) And if the fix is not feasible in gecko for 1.3,
> > we could use this ugly approach (totally disagree with this kind of
> > workarounds)
> 
> Please make sure there is a bug on file for tracking the gecko fix. I didn't
> see one referenced anywhere in this bug, and it would be bad for us to lose
> track of this.

Bug 977598 has been created for this purpose. Thanks!
Attachment #8382004 - Flags: review?(jmcf)
Cristian, instead of the hack, can you try with just touching the .top property of the right div? That would make us reflow, but I have a hard time convincing myself that we can land that patch...
Hi Fabrice, what do you mean with the right div? style.top?
(In reply to Cristian Rodriguez (:crdlc) from comment #32)
> Hi Fabrice, what do you mean with the right div? style.top?

yep. I have no idea with part of the markup to touch to trigger the right reflow though.
Comment on attachment 8382832 [details]
Patch v1 v1.3

I've changed the code to repaint the contact list after existing from search mode. Basically, playing with the top property and right container the issue is not fixed. Then, I decided to toggle a class name that adds a border bottom whose color is the same than contact list's background and extremely thin

document.getElementById('view-contacts-list').classList.toggle('repaint');

.repaint {
  border-bottom: 0.001rem #fff;
}
Attachment #8382832 - Flags: review+ → review?(jmcf)
update Milestone to S3 March 14, since it's almost done
Target Milestone: 1.4 S2 (28feb) → 1.4 S3 (14mar)
Comment on attachment 8382832 [details]
Patch v1 v1.3

I've tested it and works ok

thanks
Attachment #8382832 - Flags: review?(jmcf) → review+
Comment on attachment 8382832 [details]
Patch v1 v1.3

Thanks for addressing the changes. I am also adding verifyme for QA to help verify this, once it lands on the 1.3 branch.
Attachment #8382832 - Flags: approval-gaia-v1.3?(fabrice) → approval-gaia-v1.3+
Keywords: verifyme
Merged in v1.3:

https://github.com/mozilla-b2g/gaia/commit/8bf848ce79ba5299b9bfe321cb8cc1585c9aa696
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Verified fixed in v1.4. The contacts list and header always display appropriately.
Environmental Variables:
Device: Buri v1.4 Moz RIL
BuildID: 20140304040200
Gaia: 6df4533f14ec2645bb13d8a803a5151583ca13a8
Gecko: 529b86b92b1d
Version: 30.0a1
Firmware Version: v1.2-device.cfg
Status: RESOLVED → VERIFIED
is it verified fixed in v1.4? It is just available for v1.3 per comment 24
(In reply to Cristian Rodriguez (:crdlc) from comment #40)
> is it verified fixed in v1.4? It is just available for v1.3 per comment 24

Ah - I see what happened here. Yeah, the testing was supposed to only happen on 1.3. Reverting flags.
Status: VERIFIED → RESOLVED
Closed: 10 years ago10 years ago
Tested and working
Hamachi
1.3
Platform version: 28.0
Build ID:20140306111624
Git commit: 8aed4faf
Status: RESOLVED → VERIFIED
Blocks: 983176
You need to log in before you can comment on or make changes to this bug.