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

VERIFIED FIXED

Status

Firefox OS
Gaia::Loop
--
major
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: Javier de Prado, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

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

(Reporter)

Description

4 years ago
Device: FireE
Loop version: 08b040a
Build: flame_light-JB.user.master.B-56.Gecko-cc3c2e4.Gaia-8dd303f
(Reporter)

Updated

4 years ago
Blocks: 1036490
Severity: normal → major
(Reporter)

Comment 1

4 years ago
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?

Updated

4 years ago
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.
(Reporter)

Comment 3

4 years ago
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
(Reporter)

Comment 5

4 years ago
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]
(Reporter)

Comment 6

4 years ago
+ ... 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)
Depends on: 1068635
Depends on: 1081873
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+ → ---
(Reporter)

Updated

4 years ago
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)

Comment 15

4 years ago
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
Last Resolved: 4 years ago
Resolution: --- → FIXED
(Reporter)

Comment 18

4 years ago
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).
(Reporter)

Comment 19

4 years ago
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.