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)
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
Reporter | ||
Comment 1•10 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?
Comment 2•10 years ago
|
||
(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•10 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.
Comment 4•10 years ago
|
||
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
Updated•10 years ago
|
Assignee: nobody → borja.bugzilla
Updated•10 years ago
|
Whiteboard: [mobile app] → [mobile app][blocking]
Updated•10 years ago
|
Status: NEW → ASSIGNED
Updated•10 years ago
|
Priority: -- → P2
Reporter | ||
Comment 5•10 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.
Updated•10 years ago
|
Priority: P2 → --
Whiteboard: [mobile app][blocking] → [mobile app][blocking][tef-triage]
Reporter | ||
Comment 6•10 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,
Comment 7•10 years ago
|
||
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.
Comment 8•10 years ago
|
||
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)
Comment 9•10 years ago
|
||
(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
Comment 10•10 years ago
|
||
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)
Comment 12•10 years ago
|
||
(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.
Reporter | ||
Updated•10 years ago
|
Whiteboard: [mobile app][blocking][tef-triage] → [mobile app][blocking][tef-triage][Test-Run1]
Comment 14•10 years ago
|
||
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)
Updated•10 years ago
|
Assignee: crdlc → nobody
Comment 16•10 years ago
|
||
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
Comment 17•10 years ago
|
||
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
Reporter | ||
Comment 18•10 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•10 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.
Description
•