933561 - App does not come to foreground if user quickly toggles between home screen and app

Status: RESOLVED FIXED

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

Description

[Sotaro Ikeda [:sotaro]]

By the following STR. An application becomes not to come to foreground even when user touch it.

SRT
-[1] Show home screen.
-[2] Touch 'Contact app'
-[3] Soon after [1], touch home button
     Contact app's state changed to background by [3].

Continue [2] and [3] very quickly several times. After that, Contact app does not come to foreground even when user touches Contact app's icon. This could happen to another apps.

- ROM type: oz Build RIL
- OS version:b2g v1.3
- hardware: hamachi
- build id:20131029040205
- gecko: 5fff78955164c6c4512bfbe112bf27f6ba0c6969
- gaia: 92c097fd7ac9886f937d9decb0e03ab673deaa1b

Comment 1

[Sotaro Ikeda [:sotaro]]

This problem backs to normal, when user lock/unlock the screen.

Comment 2

[Sotaro Ikeda [:sotaro]]

Similar thing could happen also on v1.2 hamachi. It is more difficult reproduce than v1.3.

STR
-[1] Show home screen.
-[2] Touch one app shown on the bottom of the homescreen app.
        Phone, Messages, Contacts or Browser
-[3] Soon after [1], touch home button
     The app's state changed to background by [3].

Continue [2] and [3] very very quickly a lot of times. Selection of the app is changed randaomly each iteration. If the problem happens, the problem does not back to normal, even when user lock/unlocks the screen.

Comment 3

[Jason Smith [:jsmith]]

Actually - let's check if this reproduces on 1.1 as well first.

Comment 4

[gbennett]

- Unable to repro issue -
Environmental Variables:
Device: Leo 1.1 mozRIL
BuildID: 20131101041316
Gaia: 39b0203fa9809052c8c4d4332fef03bbaf0426fc
Gecko: 31fa87bfba88
Version: 18.0

Comment 5

[Cristian Rodriguez (:crdlc)]

Maybe system component?

Comment 6

[Preeti Raghunath(:Preeti)]

regression for 1.2 as well.

Comment 7

[Tony Nguyen]

I was able to reproduce this issue on Buri 1.2 under certain circumstances. The issue will appear if the device was flashed from 1.3 -> 1.2 but without a reset. When I flashed the device to 1.2 and then reseting, I was not able to repro the issue at all. I found that the issue was first broken on 1.3 build: 20131017040202. 

Last working build: 
Environmental Variables:
BuildID: 20131016040202
Gaia: 3d4f1107e6e91e5f5649edc0f2565ac837111d7d
Gecko: 9f63bbc00527
Version: 27.0a1

First broken build:
Environmental Variables:
BuildID: 20131017040202
Gaia: 616e87af0133496620aea89f21ca5d37acedf466
Gecko: 423b9c30c73d
Version: 27.0a1

Comment 8

[bhavana bajaj [:bajaj]]

Tim, can you please help with an owner here ?

Comment 9

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

Alive, a possible old regression from your patches?

Comment 10

[Jason Smith [:jsmith]]

The only patch that seems to be probable cause of this regression is bug 919864.

Comment 11

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

There is really few stuff landed in v1.2 and from https://bugzilla.mozilla.org/show_bug.cgi?id=933561#c7
and the git log I don't think there's a regression from work to cause this.

Will still check what's root cause.

Comment 12

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

Investigating.

Comment 13

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

(In reply to Jason Smith [:jsmith] from comment #10)
> The only patch that seems to be probable cause of this regression is bug
> 919864.

Are you sure by reverting it to check?

Comment 14

[Jason Smith [:jsmith]]

(In reply to Alive Kuo [:alive][NEEDINFO] from comment #13)
> (In reply to Jason Smith [:jsmith] from comment #10)
> > The only patch that seems to be probable cause of this regression is bug
> > 919864.
> 
> Are you sure by reverting it to check?

Haven't tried directly - this was just by analyzing the commit log in the system app for potential patches that could have caused this based on the regression range.

Comment 15

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

Hi, I believe this is a bug of homescreen.
The root cause is homescreen expecting it's getting visibilitychange event one any app is launching.
However in this test we just canceling the opening process of the app and doesn't change visibility of homescreen app,
so homescreen just won't get visibilitychange event and it cannot launch any app after this.

I don't think if the user tapping the homescreen+app quickly we should change visibility of homescreen to false otherwise we would see the odd homescreen(transparent).

Comment 16

[Jason Smith [:jsmith]]

I guess that makes bug 919864 not being the cause of the issue then. Let me look at the homescreen commit log.

Comment 17

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

Let me know if you want me to fix the homescreen issue or you need my help.
I'll try to provide a patch if I'm not occupied on other stuff later today.

Comment 18

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

One more info:
If you get stuck in launching app from dock, tapping any app on page area or switch to another page and tap would work again.

It's because the olist property of Page object is changed. The dock's olist is still blocked but all the other page's olist is free --- until you crash it by the repro steps.

This design is somewhat strange to me.....

(In reply to Jason Smith [:jsmith] from comment #14)
> (In reply to Alive Kuo [:alive][NEEDINFO] from comment #13)
> > (In reply to Jason Smith [:jsmith] from comment #10)
> > > The only patch that seems to be probable cause of this regression is bug
> > > 919864.
> > 
> > Are you sure by reverting it to check?
> 
> Haven't tried directly - this was just by analyzing the commit log in the
> system app for potential patches that could have caused this based on the
> regression range.

Next time please do not mark the dependency that quickly, it's confusing me. Thanks!

Comment 19

[Cristian Rodriguez (:crdlc)]

Attachment: Patch v1

Comment 20

[Cristian Rodriguez (:crdlc)]

Merged in master:

https://github.com/mozilla-b2g/gaia/commit/4e2a68ccd5eb0af576855777b752b4053477575e

Comment 21

[bhavana bajaj [:bajaj]]

Ni :jford here to help with uplift.

Comment 22

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

I was not able to uplift this bug to v1.2.  If this bug has dependencies which are not marked in this bug, please comment on this bug.  If this bug depends on patches that aren't approved for v1.2, we need to re-evaluate the approval.  Otherwise, if this is just a merge conflict, you might be able to resolve it with:

  git checkout v1.2
  git cherry-pick -x -m1 4e2a68ccd5eb0af576855777b752b4053477575e
  <RESOLVE MERGE CONFLICTS>
  git commit

Comment 23

[Cristian Rodriguez (:crdlc)]

Merged in v1.2

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

Comment 24

[bhavana bajaj [:bajaj]]

Thanks :crdlc, :jhford !

Comment 25

[Josh Schmitt [Joshs]]

This issue still where quickly selecting between 'Home' and an App. Occurs on the latest Buri 1.2 and Master 1.3 builds. It is being tracked by bug 943317

1.2 Environmental Variables:
Device: Buri v1.2 COM RIL
BuildID: 20131205004003
Gaia: 0659f16b9790b1cf9eba4d80743fcc774d2ffe3a
Gecko: af2c7ebb5967
Platform Version: 26.0
RIL Version: 01.02.00.019.102 
Firmware Version: V1.2_20131115

1.3 Environmental Variables:
Device: Buri v1.3 MOZ RIL
BuildID: 20131205040201
Gaia: 1dd0e5c644b4c677a4e8fa02e50d52136db489d9
Gecko: 725c36b5de1a
Version: 28.0a1
Firmware Version: V1.2_20131115

Comment 26

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

This is still problemantic once you launch an app with telephony permission and you have a SIM PIN.
The SIM PIN dialog would prevent the app to be opened so there would be no visibilitychange event.

This may be wrong but I still recommend homescreen at least has a timer to cancel the disable state.