Closed Bug 1045598 Opened 10 years ago Closed 10 years ago

[Loop] Not sharing Contact List, Loop should use identities instead of trying to use non available contact information.

Categories

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

x86
Gonk (Firefox OS)
defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: javier.deprado, Unassigned)

References

Details

(Whiteboard: [mobile app][blocking][tef-triage][Test-Run1])

Device: FireE Loop version: 08b040a Build: flame_light-JB.user.master.B-56.Gecko-cc3c2e4.Gaia-8dd303f
Blocks: 1036490
Severity: normal → major
STR: 1. Install Loop app 2. Open Loop app and follow the wizard until the window that shows the option to allow Loop access to the CONTACT LIST. 3. DON'T ALLOW. 4. Try to make a call ACTUAL RESULT: Contact list is displayed. Why am I asked for allow or not allow Loop to access to the contact list?
Whiteboard: [mobile app]
(In reply to JPrado from comment #1) > > ACTUAL RESULT: Contact list is displayed. > Why am I asked for allow or not allow Loop to access to the contact list? We are not showing any contact list in Loop, what we show is the call log with contact information in it. We are asked for this permission cause Loop makes a direct query to the Contacts API to obtain the contact information associated to the identity of the caller/callee in a Loop call. I just tested it and we are not allowed to get the contact information for an outgoing or incoming Loop call, which is the expected behavior. What we are not doing ok is that we don't show any information in the call screen and we don't log the call in the action log if we don't have access to the contact information associated to that call. We should use the caller/callee identity instead.
Summary: [Loop] Not sharing Contact List, Loop can access to the contacts list. → [Loop] Not sharing Contact List, Loop should use identities instead of trying to use non available contact information.
Ok. I just tested on fireE, LoopClient: c10ba2b and it is still happening. 1.- Is not showing any information in the call screen 2.- No entry is not showing in call log.
This issue still occurs on the latest 2.0 build with the v165 KK base. Calls made with access to the contacts page denied are not shown in the call log. Environmental Variables: Device: Flame 2.0 BuildID: 20140820030000 Gaia: 806d37a264743e04a3e1493136486f3e00124e1e Gecko: 6329352ca531b977979451e77e5862af485388b2 Version: 32.0 (2.0) Firmware Version: v165 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Loop version: 8c71431
Assignee: nobody → borja.bugzilla
Whiteboard: [mobile app] → [mobile app][blocking]
Status: NEW → ASSIGNED
Priority: -- → P2
Tested on flame, LoopClient: 3cd2086, build flame-kk.user.v2.0.gecko-6cc9a4d.gaia-31434a3, RAM=512M, It is still happening. 1.- Is not showing any information in the call screen 2.- No entry is not showing in call log.
Priority: P2 → --
Whiteboard: [mobile app][blocking] → [mobile app][blocking][tef-triage]
+ ... when the screen of sharing contact list appears, pushing home button or switching off the screen, It seems you don't allow to share Contact list and occurs the same: 1.- Is not showing any information in the call screen 2.- No entry is not showing in call log. Tested on flame, LoopClient: 0d03a08, build flame-KK.eng.v2.0.B-9.Gecko-d87b9af.Gaia-0658006, RAM=512M,
Just adding EXPECTED RESULT: If we don't allow Loop application access to the Contacts application and receive or make Loop calls, we should show in the Call Log the corresponding entries showing the Loop identities of the users we are calling/receiving calls.
Hi Julien, I would like to know how detect if users don't allow us to access to contact list from js. The navigator.mozContacts object is available with all its methods. I tested it: var req = navigator.mozContacts.getRevision(); req.onsuccess = () => { // Do something } req.onerror = () => { console.error('mozContacts is not available'); onerrorCB(); }; but neither onsuccess nor onerror are called when the permission is denied. I thought that it should work according to this code: http://hg.mozilla.org/mozilla-central/file/e0d9ad4be606/dom/contacts/ContactManager.js#l441 Is something wrong with my thoughts? any bug on Gecko? Thanks a lot for your time and support
Assignee: borja.bugzilla → crdlc
Flags: needinfo?(felash)
(In reply to Cristian Rodriguez (:crdlc) from comment #8) > but neither onsuccess nor onerror are called when the permission is denied. > I thought that it should work according to this code: > http://hg.mozilla.org/mozilla-central/file/e0d9ad4be606/dom/contacts/ > ContactManager.js#l441 > > Is something wrong with my thoughts? any bug on Gecko? > > Thanks a lot for your time and support This might be because of bug 1068635
Cristian, I think like you here, it should work. We can wait for resolution of bug 1068635 like ferjm suggests. In the mean time, you can try a smaller application. Maybe dev_apps/uitest and dev_apps/uitest_privileged already have this code to quickly test too.
Flags: needinfo?(felash)
See bug 1081873 comment 3 for blocking rationale.
blocking-b2g: --- → 2.0+
(In reply to Andrew Overholt [:overholt] from comment #11) > See bug 1081873 comment 3 for blocking rationale. thanks a lot Andrew!, it's really important we can fix the issue reported here. In this bug we will handle the fix in the Loop mobile client (if it's necessary) so it does not need be blocked with blocking-b2g flag, with bug 1068635 and bug 1081873 set as 2.0+ are enough to resolve the issue in the platform. Thanks a lot for taking care of it.
Ah, I'll remove blocking-b2g:2.0+ :)
blocking-b2g: 2.0+ → ---
Whiteboard: [mobile app][blocking][tef-triage] → [mobile app][blocking][tef-triage][Test-Run1]
Before I approved bug 1068635 and bug 1081873 to land on 2.0/2.1 branches, to resolve this issue, Javier can you please help verifying the issue on trunk and making sure there are no unexpected fallouts so we are safe to uplift? Thanks!
Flags: needinfo?(javier.deprado)
Tested on trunk and works fine.
Flags: needinfo?(javier.deprado)
Assignee: crdlc → nobody
Checking the gecko patches bug 1068635 and bug 1081873, already landed in master, we confirmed that this bug is still not happening, so no more work is needed here. Anyway we are not resolving this bug until the gecko patches are uplifted to 2.0, just to ensure that all is working as expected in 2.0
Resolving this issue as bug 1068635 and bug 1081873 have been uplifted to 2.0 and I am not able to reproduce it on latest 2.0 version with loop master version. Device: Flame Loop version: 5806319 Build: flame-KK.user.v2.0.184based.B-48.Gecko-cb1c9ea.Gaia-2183b4f
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Verified on FLAME (184based.B-49(user), B-43(eng).Gecko-675d616.Gaia-2183b4f), Loop version 1.1: 5806319 It's still failing on FireE, v2.0-SW2E3-1 (waiting for uplifted).
Verified on FireE, firee-kk-v2.0-SW2E5-4, loop version, 1.1: cc87bd0
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.