Description: During a call with loop app, if user presses home, a grey notifcation will appear on the homescreen with the current view of the camera in the middle Repro Steps: 1) Update a Flame device to BuildID: 20141107001205 2) Open Loop app 3) Make a call with loop app 4) During the call press home button 5) Observe grey notification Actual: Grey notifcation appears Expected: Proper Loop notifcation appears. "Firefox Hello" Environmental Variables: Device: Flame 2.1 (319mb) KK Shallow Flash BuildID: 20141107001205 Gaia: 6295f6acfe91c6ae659712747dd2b9c8f51d0339 Gecko: 8c23b4f2ba29 Version: 34.0 (2.1) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Repro frequency: 3/4 See attached: Screenshot, Logcat

This issue does not occur on Flame 2.0 Results: Notifcation shows properly Flame 2.0 Device: Flame 2.0 (319mb)(Kitkat Base)(Shallow Flash BuildID: 20141107000206 Gaia: d3e4da377ee448f9c25f908159480e867dfb13f3 Gecko: 9836e9d81357 Version: 32.0 (2.0) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 ------------------------------------------------------- This issue also occurs on Flame 2.2 Results: Grey notifcation appears Flame 2.2 Device: Flame 2.2 Master (319mb)(Kitkat Base)(Shallow Flash) BuildID: 20141107040206 Gaia: 779f05fead3d009f6e7fe713ad0fea16b6f2fb31 Gecko: 64f4392d0bdc Version: 36.0a1 (2.2 Master) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

[Blocking Requested - why for this release]: Regression, unusual / unexpected functionality, poor UX

Shell, can you please help re-direct this bug to the right folks. I think it'll help to have a regression window from QA and we should do necessary backouts depending on what the original culprit was.

Bug 927862 seems to be the cause of this issue. B2g-inbound Regression Window Last Working Environmental Variables: Device: Flame 2.1 BuildID: 20140828211200 Gaia: 8d965e7182500fd1849e8eec5ae2aca35a55af22 Gecko: efb4f3f291a4 Version: 34.0a1 (2.1) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 First Broken Environmental Variables: Device: Flame 2.1 BuildID: 20140828223200 Gaia: 6f270b9fee0c1f09863f5e1aa640937a07c7fdae Gecko: 18ed4643a705 Version: 34.0a1 (2.1) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Last Working gaia / First Broken gecko - Issue does NOT occur Gaia: 8d965e7182500fd1849e8eec5ae2aca35a55af22 Gecko: 18ed4643a705 First Broken gaia / Last Working gecko - Issue DOES occur Gaia: 6f270b9fee0c1f09863f5e1aa640937a07c7fdae Gecko: efb4f3f291a4 Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/8d965e7182500fd1849e8eec5ae2aca35a55af22...6f270b9fee0c1f09863f5e1aa640937a07c7fdae

Broken by Bug 927862 - can you take a look?

This is not regressing - I believe this is a loop bug. The loop should listen to resize event on 'window' to show the green on call status, but from current UI, I think they are doing something wrong. The green status show on startup.

Hi you had mentioned this, and I think it's not me to control how you display but your app, please help to check. You could refer callscreen code.

I also believe this might be on Loop's side. I would love to help here, but I am not really working on Loop anymore.

Borja,can you have a look at it?

After landing patch in bug 1099023, I can not reproduce this bug anymore in 2.1 FxOS version so this issue should be already solved. Salvador, I've uploaded a video where you can see the fix https://www.youtube.com/watch?v=MRSo7m9yCh4, device M has the patch in bug 1099023 and M device Loop master (without the patch) and both are in v2.1. What I've seen, and independently of the patch, is that after some seconds the Loop status bar disappears and for hanging up the Loop call I have to open the notification tray and launch the Loop call screen again for finishing the Loop call (it seems a new behavior for 2.1/2.2 version). Massimo can you have a look at it? Thanks a lot!

Yes, I can reproduce this. Not sure if this is the expected behavior for 2.1 and higher or is a bug.

(In reply to mbarone from comment #12) > Yes, I can reproduce this. Not sure if this is the expected behavior for 2.1 > and higher or is a bug. Alberto, do you know if this is a new feature?

Hi there! I think that's expected behavior for 2.1/2.2. The static call status banner has been replaced by the ambient indicator animation (which indicates you are in a call) + a notification, moving all the actions to the utility tray. I'm going to ni :alive to double check I'm not wrong. Thanks!

(In reply to Maria Angeles Oteo (:oteo) from comment #11) > After landing patch in bug 1099023, I can not reproduce this bug anymore in > 2.1 FxOS version so this issue should be already solved. > > Salvador, I've uploaded a video where you can see the fix > https://www.youtube.com/watch?v=MRSo7m9yCh4, device M has the patch in bug > 1099023 and M device Loop master (without the patch) and both are in v2.1. > > What I've seen, and independently of the patch, is that after some seconds > the Loop status bar disappears and for hanging up the Loop call I have to > open the notification tray and launch the Loop call screen again for > finishing the Loop call (it seems a new behavior for 2.1/2.2 version). > Massimo can you have a look at it? Thanks a lot! > > *** This bug has been marked as a duplicate of bug 1099023 *** Yes, it is a feature implemented in bug 927862 and there is a spec in the user story field, please check that out.