1035507 - [B2G][Camera]Tapping on a notification while in an app causes the device to get stuck in that app

Status: RESOLVED DUPLICATE of bug 1037041

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Andrew Stole [:astole]]

Attachment: logcat

Tapping on a notification while in an app causes the device to be stuck and the device has to be restarted in order to exit the app. 

Repro Steps:
1) Update a Flame to BuildID: 20140707000200
2) Launch an app (Camera app was used for logcat)
3) Receive a notification
4) Tap on the notification

Actual:
Device gets stuck in the app from step 2

Expected:
The notification launches in the correct app

2.0 Environmental Variables:
Device: Flame 2.0
BuildID: 20140707000200
Gaia: ef67af27dff3130d41a9139d6ae7ed640c34d922
Gecko: f53099796238
Version: 32.0a2
Firmware Version: v122

Repro frequency: 100%
See attached: logcat

Comment 1

[Jason Smith [:jsmith]]

This is missing a QAnalyst-Triage? flag

Comment 2

[Peter Bylenga [:PBylenga]]

Adding qawanted for flame branch checks with memory set to 273mb.

Comment 3

[Cody Roesch [:croesch]]

This bug repro's on: Flame 2.1 Master, Flame 2.0

Actual Results: With Mem set to 273, tapping on notifications that appear while inside of apps can lock the user into that app. Tapping the home button does not allow the user to leave.

Environmental Variables:
Device: Flame Master
Build ID: 20140708061447
Gaia: 740faa5d0060fb218b407cf224330654ddf833a5
Gecko: 8bfe3372f848
Version: 33.0a1 (Master)
Firmware Version: v122
-----------------------------------------------
Environmental Variables:
Device: Flame 2.0
Build ID: 20140708071430
Gaia: 444efc47370736a7bc57cc72a1ec00f3cc5f7e92
Gecko: c3683c06f6d8
Version: 32.0a2 (2.0)
Firmware Version: v122

-----------------------------------------------
-----------------------------------------------

This bug does NOT repro on: Flame 1.4

Actual Result: At 273mb, tapping on message, missed call etc. notifications within different open apps, does not cause the user to be locked into the app.

Environmental Variables:
Device: Flame 1.4
Build ID: 20140708070432
Gaia: 229864ff4ad90899f017341b9e81ed0b53498c66
Gecko: 7e146a1d7542
Version: 30.0 (1.4)
Firmware Version: v122

Comment 4

[Joshua Mitchell (Inactive)]

nomming for 2.0, issue is a regression and a performance issue; user can become locked into an app

Comment 5

[Jason Smith [:jsmith]]

(In reply to Joshua Mitchell (Joshua_M) from comment #4)
> nomming for 2.0, issue is a regression and a performance issue; user can
> become locked into an app

I don't think this is a perf issue - this feels like a functionality issue that happens to show up in a low memory environment.

Comment 6

[Gregor Wagner [:gwagner]]

What notification did you receive?

Comment 7

[Jason Smith [:jsmith]]

QA Wanted to answer comment 6.

Comment 8

[Pi Wei Cheng [:piwei] (inactive)]

(In reply to Gregor Wagner [:gwagner] from comment #6)
> What notification did you receive?

I used SMS notification for testing.

But I found that this doesn't actually reproduce on every app every time, like Dialer app for example, doesn't always reproduce the bug. This bug seems to be more reliably reproduced while DUI is in Camera app and receives an SMS.

Comment 9

[Jason Smith [:jsmith]]

This is missing a QAnalyst-Triage? workflow

Comment 10

[Joshua Mitchell (Inactive)]

Not adding regression window for this issue - a regression window will be very problematic and most likely incorrect in the end due to unreliable and variable repro - "this doesn't actually reproduce on every app every time".

Comment 11

[Jason Smith [:jsmith]]

(In reply to Joshua Mitchell (Joshua_M) from comment #10)
> Not adding regression window for this issue - a regression window will be
> very problematic and most likely incorrect in the end due to unreliable and
> variable repro - "this doesn't actually reproduce on every app every time".

I don't think that's good enough. comment 0 & comment 8 are indicating conflicting information on reproduction rate. Can you please get updated STR here with an accurate reproduction rate indicated?

Comment 12

[Gregor Wagner [:gwagner]]

We fixed similar issues on the tarako branch afaik. I expect it to be specific to the notification you get. The dialer screen is in process now afaik so it should work. Following a sms notification has to start the SMS app and we might fail because of OOM. Julien, do you know if we have any patches on the tarako branch that might help here?

Comment 13

[Julien Wajsberg [:julienw]]

In v1.3t we had the issue that the notification was not displayed (because the app was in background or something and so it was killed).

Here I don't think that the issue. Also I don't see how failing to launch an app would lock the user to the previous app.

Moreover it seems to work for me on Buri (256MB too, right?) although I don't have the latest build.

Comment 14

[Pi Wei Cheng [:piwei] (inactive)]

Updated STR:
1) With no other apps running, launch Camera app (if prompted for Geolocation sharing, tap don't share)
2) While in Camera, have another phone send an SMS to DUI
3) When SMS notification appears, tap on it

Device is then locked to the Camera app. Tapping on Home button would make the Status bar become transparent as if going back to Homescreen but it's not. If I swipe Notification bar down, and tap on gear icon to access Settings, Settings can still be accessed, but tapping on Home in Settings will go back to Camera app again.

- Flame 2.1 master build ID 20140708201331:
  5 repro out of 5 attempts

- Flame 1.4 build ID 20140709075131:
  0 repro out of 5 attempts.

There was one attempt tapping on SMS notification the phone does nothing. However Home could still be accessed. This attempt was not counted toward the 5 attempts.

----
I was having a difficult time finding a window yesterday because of the wide range of apps and notification types that this bug could and could not occur. Earlier Flame Central builds can't recognize the SIM, luckily the regression seems to have happened after the SIM issue was fixed, but then there are some builds in the middle (May) that recognizes SIM but can't receive/send SMS, and so the window was going nowhere.

I could re-try finding a window using this specific STR, but I'm not confident because SMS doesn't seem to always work in the range of dates that this bug started to occur. And overall the phone is just laggy in 273MB of RAM, so sometimes if I tap on SMS notification, the phone doesn't do anything, then I thought it is repro'ing the bug, but tapping on Home button it actually goes back to Home after 3 seconds. At this stage I have to reboot the phone or Factory Reset it or both to re-test. On top of that, with each factory-reset or flashing of new build, bug 1008050 occurs. It takes a long time.

Comment 15

[Joshua Mitchell (Inactive)]

very nicely stated Pi Wei;
 re-adding  [lead-review-], I believe that was subtracted by accident.

Comment 16

[Jason Smith [:jsmith]]

Alright - better to diagnose this by development directly then rather than trying to get a window, as getting a window will be unreliable.

Comment 17

[Michael Henretty [:mikehenrty][:mhenretty]]

I am able to reproduce with the latest master on flame running at 273mb. I have some more information.

When the sms comes in, cost control and sms apps get launched in the background. This causes the OOM manager to kill the homescreen in the background. Then when we click on the notification toaster I see this error in logcat:

E/GeckoConsole(  310): [JavaScript Error: "TypeError: this.element is null" {file: "app://system.gaiamobile.org/js/app_window.js" line: 303}]



Next, when I click the home button again the homescreen app does indeed launch in the background, but it never comes to the foreground. I also see this error in logcat:

E/GeckoConsole( 1773): Content JS ERROR at app://verticalhome.gaiamobile.org/js/configurator.js:124 in loadSVConfFileError: Failed parsing singleVariant configuration file [js/singlevariantconf.json]:  [Exception... "File error: Not found"  nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame :: app://verticalhome.gaiamobile.org/js/configurator.js :: loadFile :: line 41"  data: no]

Comment 18

[Candice Serran (:cserran)]

Hema, 

Can you please take a look at this?  We think this is a media blocker.

Comment 19

[Hema Koka [:hema]]

Candice, 

From the comments and comment # 17, this looks systems related and not specific to camera app. It also happens with dialer. Please have someone in the systems team investigate further (camera folks are also busy investigating camera specific blocking issues at the moment)

Thanks
Hema

Comment 20

[Michael Henretty [:mikehenrty][:mhenretty]]

(In reply to Hema Koka [:hema] from comment #19)
> Candice, 
> 
> From the comments and comment # 17, this looks systems related and not
> specific to camera app. It also happens with dialer. Please have someone in
> the systems team investigate further (camera folks are also busy
> investigating camera specific blocking issues at the moment)
> 
> Thanks
> Hema

It is possible I was seeing other issues in the camera unrelated to this bug. For instance, when I run the camera I see the following logs repeatedly (10's of times per second):

E/mm-camera(  394): msg_bus_post_msg: bus_msg type is not valid
E/mm-camera(  394): isp_ch_util_hw_notify_sof: meta dump data to bus error
E/mm-camera(  394): msg_bus_post_msg: bus_msg type is not valid
E/mm-camera(  394): stats_port_event: Failure posting to the bus!

Also the app was crashing periodically, and since I was unable to reproduce the notification issue in other apps I assumed this bug was related to camera. However, I will take another look and try to reproduce this in the dialer.

Comment 21

[Justin D'Arcangelo [:justindarc]]

(In reply to Michael Henretty [:mhenretty] from comment #20)
> (In reply to Hema Koka [:hema] from comment #19)
> > Candice, 
> > 
> > From the comments and comment # 17, this looks systems related and not
> > specific to camera app. It also happens with dialer. Please have someone in
> > the systems team investigate further (camera folks are also busy
> > investigating camera specific blocking issues at the moment)
> > 
> > Thanks
> > Hema
> 
> It is possible I was seeing other issues in the camera unrelated to this
> bug. For instance, when I run the camera I see the following logs repeatedly
> (10's of times per second):
> 
> E/mm-camera(  394): msg_bus_post_msg: bus_msg type is not valid
> E/mm-camera(  394): isp_ch_util_hw_notify_sof: meta dump data to bus error
> E/mm-camera(  394): msg_bus_post_msg: bus_msg type is not valid
> E/mm-camera(  394): stats_port_event: Failure posting to the bus!
> 
> Also the app was crashing periodically, and since I was unable to reproduce
> the notification issue in other apps I assumed this bug was related to
> camera. However, I will take another look and try to reproduce this in the
> dialer.

This has nothing to do with this particular issue. This is (extremely noisy) camera driver output. Tracking here: Bug 1037074 - [Camera][Gonk] The camera libraries spam logcat A LOT, need to dial is back

Comment 22

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

FYI, according to what michael told me, this might be dupe of bug 1037041.

Comment 23

[Michael Henretty [:mikehenrty][:mhenretty]]

(In reply to Alive Kuo [:alive][NEEDINFO!][Berlin 7/14-7/18] from comment #22)
> FYI, according to what michael told me, this might be dupe of bug 1037041.


Under certain conditions, the homescreen app will get killed in the background due to memory pressure. This is quite easy to do in camera, but can happen in any app (Music, Settings are also easy to repro). When homescreen is dead and the notification comes in, we try to fade out the homescreen here [1], which causes the top error mentioned in comment #17. I spoke with Alive about this issue, and it turn out :gduan already has a fix for this in bug 1037041. I flashed his patch, and the bug was fixed.

1.) https://github.com/mozilla-b2g/gaia/blob/88a22c3eafe5824e4b70f2ff639673a7534fcb4d/apps/system/js/app_window.js#L303