1107862 - [Loop] Impossible to kill the app when the sms app used for the fallback mechanism is open in background

Status: VERIFIED FIXED

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

Description

[mbarone]

Device: Fire E (Build Fire_E_user_SW_03001)
Loop: 4212078

STR
1. Log into Loop app
2. Open Contact app and create a new contact (no Loop user) with a phone number, only.
3. Make a loop call to the contact created on step 2 from the Contact app
4. Once the fallback mechanism is shown, send the sms. Don't close the sms app.
5. Click on home button and open again Contact app
5. Make a loop call to the same contact

ACTUAL RESULT
The fallback is not displayed and is not possible to kill the loop app

EXPECTED RESULT
The fallback mechanism should be displayed

Comment 1

[Maria Angeles Oteo (:oteo)]

Just adding that this bug was also happening in the 1.1 version delivered to the OEM, so it's not a regression due to the new bugs uplifted to 1.1 branch for the next update.

Comment 2

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Pointer to Github PR https://github.com/mozilla-b2g/firefoxos-loop-client/pull/367

This is mostly an issue with the 'websms/sms' activity as the `onsuccess` callback of the activity doesn't get called unless the user hits the close button in the Messaging app. Either way I ended up with a patch that fixes the issue. Borja, may I have some feedback about the patch and what to do please? I mean, take this patch as a workaround or discuss this issue with the Messaging app folks.

Comment 3

[Antonio Manuel Amaya Calvo (:amac)]

This is not a problem with the messaging app. We should not call the activity from the attention screen. As such, closing the attention screen earlier is the right thing to do, IMHO.

Comment 4

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Antonio Manuel Amaya Calvo (:amac) from comment #3)
> This is not a problem with the messaging app. We should not call the
> activity from the attention screen. As such, closing the attention screen
> earlier is the right thing to do, IMHO.

Actually we are not calling the activity from the attention screen context. Current patch closes the attention screen (call screen) earlier so it solves the issue somehow.

Comment 5

[Antonio Manuel Amaya Calvo (:amac)]

I don't think it matters wether the activity is called from inside what we consider to be the attention screen or not. What it matter is that it's called from the same process that has an attention opened. That's why it cannot be killed and that's why closing it earlier fixes it and it's the right thing to do :)

Comment 6

[Borja Salguero [:borjasalguero]]

The bug is not related with the Attention screen itself, it's a tricky bug to find, but simple to fix (and actually Jose Antonio found the solution :) ). The problem is that 'Share' screen is shown until the SMS is successfully sent (when the SMS App returns this, and it happens when we close the SMS App).
If we are not closing the SMS App, when the second outgoing call fallback happens, it executes [1]. However, as the Share panel was shown, there is no transition and, therefore, no callback executed (so the attention screen is not closed, and this is the bug).
Just moving the line to [2] the bug is solved.

Jose Antonio, could you create the patch for master, and then apply to 1.1? Thanks!


[1] https://github.com/mozilla-b2g/firefoxos-loop-client/pull/367/files#diff-faab1f116ac973e06a91f9b94ad99ca8R355
[2] https://github.com/mozilla-b2g/firefoxos-loop-client/pull/367/files#diff-a9d792224bd7e9c0cec35ca110b79972R46

Comment 7

[Borja Salguero [:borjasalguero]]

Comment on attachment 8532603 [details] [review]
Pointer to Github PR https://github.com/mozilla-b2g/firefoxos-loop-client/pull/367

Great job! This is a really tough to find bug! Could you create a patch for master, and then apply to v1.1 as well? Please fix the comment I left in the PR before merging!

Comment 8

[José Antonio Olivera Ortega [:jaoo]]

Attachment: [master] Pointer to Github PR https://github.com/mozilla-b2g/firefoxos-loop-client/pull/370

Patch for master branch. Carrying out r=borjasalguero

Comment 9

[José Antonio Olivera Ortega [:jaoo]]

Attachment: [1.1] Pointer to Github PR https://github.com/mozilla-b2g/firefoxos-loop-client/pull/372

Patch for 1.1 branch. Carrying out r=borjasalguero

Comment 10

[José Antonio Olivera Ortega [:jaoo]]

Comment on attachment 8533563 [details] [review]
[master] Pointer to Github PR https://github.com/mozilla-b2g/firefoxos-loop-client/pull/370

As several changes has been added I think that a new review is the right thing to do. Would you mind Borja? Thanks!

Comment 11

[José Antonio Olivera Ortega [:jaoo]]

Landed on master branch at:

https://github.com/mozilla-b2g/firefoxos-loop-client/commit/5e5404c9a35b3fe72a0847c1e55d98f8f3da2263

Landed on 1.1 branch at:

https://github.com/mozilla-b2g/firefoxos-loop-client/commit/6900ad7e47bb49a5acc8ac6463aea66da36daa4d

Comment 12

[Loli (:lolimartinezcr)]

Tested and not working correctly. Now The fallback is displayed in background and *only* when SMS application is closed, user can see it. See video http://youtu.be/O8yb1IB4Fao

Env:
V1.1 v6900ad7
FireE comercial build

Comment 13

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Loli (:lolimartinezcr) from comment #12)
> Tested and not working correctly. Now The fallback is displayed in
> background and *only* when SMS application is closed, user can see it.

Loop uses the 'websms/sms' activity and once the message is sent Loop doesn't have control over the Messaging app. Sadly once the message is sent the app is not closed automatically (and sadly Loop cannot do it programmatically either). The feedback screen is shown always and Loop doesn't get stuck on the call screen so I would say the solution landed works for me. Thoughts?

Comment 14

[Maria Angeles Oteo (:oteo)]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #13)
> (In reply to Loli (:lolimartinezcr) from comment #12)
> > Tested and not working correctly. Now The fallback is displayed in
> > background and *only* when SMS application is closed, user can see it.
> 
> Loop uses the 'websms/sms' activity and once the message is sent Loop
> doesn't have control over the Messaging app. Sadly once the message is sent
> the app is not closed automatically (and sadly Loop cannot do it
> programmatically either). The feedback screen is shown always and Loop
> doesn't get stuck on the call screen so I would say the solution landed
> works for me. Thoughts?

Agree, the bug is fixed, it's not a perfect solución but good enough and for the time being we can not do too much to improve it.

Comment 15

[Loli (:lolimartinezcr)]

(In reply to Maria Angeles Oteo (:oteo) from comment #14)
> (In reply to José Antonio Olivera Ortega [:jaoo] from comment #13)
> > (In reply to Loli (:lolimartinezcr) from comment #12)
> > > Tested and not working correctly. Now The fallback is displayed in
> > > background and *only* when SMS application is closed, user can see it.
> > 
> > Loop uses the 'websms/sms' activity and once the message is sent Loop
> > doesn't have control over the Messaging app. Sadly once the message is sent
> > the app is not closed automatically (and sadly Loop cannot do it
> > programmatically either). The feedback screen is shown always and Loop
> > doesn't get stuck on the call screen so I would say the solution landed
> > works for me. Thoughts?
> 
> Agree, the bug is fixed, it's not a perfect solución but good enough and for
> the time being we can not do too much to improve it.

Ok, I change status to Verified