875899 - Cannot kill FB or twitter from task-switcher, after launching offline

Status: VERIFIED FIXED

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

Description

[David Palomino [:dpalomino]]

Ikura, AU116, 24/05 vendor build

This is always reproducible. This is a blocking issue, and we think it's the root cause for some of the inestabilities that we're seeing with FB and twitter. 

Steps to reproduce: 
1. Offline mode (no mobile data, no wifi)
2. Launch either facebook or twitter
3. Message "ok, you need a connection is shown" (ok)
4. Try to kill the apps from the task-switche, it seems that everything is ok, but if going to task-switcher again, both FB and twitter are there

We think this issue could be related with other extrange behaviors observed, for instance: 

- Some infrequent facebook locks
- Seen only once, launching twitter being offline, white screen appears

We do not consider this two issues as blockers, just commenting in case it could help.

Comment 1

[Daniel Coloma:dcoloma]

Adding qawanted in order to reproduce this.

Comment 2

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I wasn't able to reproduce this with the production build from the vendor.

Did you pan a lot at some point in facebook/twitter?  I think this might have something to do with the other twitter bug that was closed out.

Comment 3

[Daniel Coloma:dcoloma]

Attachment: Video

Comment 4

[Daniel Coloma:dcoloma]

An easy way to reproduce it for me is to disable Cellular Data and WiFi and reboot device.

Open FB and Twitter apps, 1-2-3 times, go to task switcher, kill one of them. it seems it has been killed but it is not. I have enclosed a video. 

I have not been able to reproduce it with Tuenti, that is the same kind of app :(

Comment 5

[Kai-Chih Hu [:khu]]

Askeing, can you help to do the testing as well? 
Alan, can you check this issue now? 

Thanks.

Comment 6

[Jason Smith [:jsmith]]

Question for QA testing:

1. Can you reproduce this on a non-ZTE device (e.g. Buri, Unagi)?

Comment 7

[Askeing Yen[:askeing][:fyen]]

Inari, 20130526, vender user build

I can reproduce follow comment 4.

1. Disable Wifi and Cell-Data then reboot first, it will be more easy to reproduce this issue.
2. Open FB or twitter
3. Click "close" to close it
4. Long-press Home button to check is it killed, if the app was killed then goto step 2

Comment 8

[Askeing Yen[:askeing][:fyen]]

(In reply to Jason Smith [:jsmith] from comment #6)
> Question for QA testing:
> 
> 1. Can you reproduce this on a non-ZTE device (e.g. Buri, Unagi)?
Unagi v1.0.1
Gaia:     26d9430df4cd670e46a208a6e4b6d77e4b27ed75
Gecko:    http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/9ce68012f9da
BuildID   20130525230202
Version   18.0

Can reproduce it.

Comment 9

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Askeing,

I cannot reproduce this with my makeshift Gaia set-up.

On step 3 of your comment 7, did you hit close while there is a "Network Error" overlay on the Facebook card, or, there is only Gecko light-blue error page?

Comment 10

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #9)
> Askeing,
> 
> I cannot reproduce this with my makeshift Gaia set-up.
> 
> On step 3 of your comment 7, did you hit close while there is a "Network
> Error" overlay on the Facebook card, or, there is only Gecko light-blue
> error page?

Never mind, Alive and I find your close button and is able to reproduce this bug.

Comment 11

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

I'm also investigating this for gaia part

Comment 12

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: Tentative patch

Alive and I have identified the cause of this bug: in kill() of window_manager.js, somehow the transition never completes and we have never call removeFrame().

If we couldn't identify a proper fix, there is a fail safe that we should probably do.

Comment 13

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: Tentative patch v2

syntax error on previous patch

Comment 14

[(inactive after 6/18) Alive Kuo [:alive]]

The root cause is the transition never happens when we close the appWindow.
I am working on identifying the problem why transform: scale(0.6) rule doesn't apply to appWindow.
If I couldn't solve this in time, we could consider to take comment 13.

Comment 15

[(inactive after 6/18) Alive Kuo [:alive]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/10011

Patch proposal:
Keep the loading state on iframe.

Comment 16

[(inactive after 6/18) Alive Kuo [:alive]]

Let recode the investigation here:
* The is another regression of bug 842627.
* Because the mozbrowloadend event is faster than the opening transition(0.3s) in app page error case, the windowReady() function is never called.
* Because the active class is set in windowOpened(), the opened app doesn't have active class.
* When we close/kill the app, the app is immediately goto 0.6 without transition because it's never active.
* The closing transition never happens so the removeFrame never being called.
* So the app couldn't be killed.

Comment 17

[(inactive after 6/18) Alive Kuo [:alive]]

v1.0.1

https://github.com/mozilla-b2g/gaia/commit/f6c52c8b3e9fb0409aeefbe4bba05dd09da19dd7

Comment 18

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I wonder why the regression of bug 842627 went undetected for a month :-/

Comment 19

[Askeing Yen[:askeing][:fyen]]

Inari
Gaia:     460bd2dbe44b5d9d6f497f5944e1b6c69db82c81

Verified.

Comment 20

[Askeing Yen[:askeing][:fyen]]

status missing due to the network problem, recover it.

Comment 21

[Jason Smith [:jsmith]]

(In reply to Askeing Yen[:askeing] from comment #20)
> status missing due to the network problem, recover it.

For verifications on 1.01, you'll want to set the status flag to verified. When you verify on trunk, you set RESOLVED --> VERIFIED in the workflow.

Comment 22

[John Ford [:jhford] CET/CEST Berlin Time]

Is this applicable to v1-train?

Comment 23

[(inactive after 6/18) Alive Kuo [:alive]]

Exactly -- no idea because there's big change between v1-train and v1.0.1
Keep watching.

Comment 24

[John Ford [:jhford] CET/CEST Berlin Time]

(In reply to Alive Kuo [:alive] from comment #23)
> Exactly -- no idea because there's big change between v1-train and v1.0.1
> Keep watching.

Could you please uplift to v1-train then?  I'm not sure which commit should be uplifted.

Comment 25

[(inactive after 6/18) Alive Kuo [:alive]]

The code in v1-train and v1.0.1 has significant change, so I don't think this needs uplift.

Comment 26

[Askeing Yen[:askeing][:fyen]]

change status base on comment 25.