Closed Bug 1095767 Opened 7 years ago Closed 7 years ago

[Loop] When user presses home during a call, a grey notifcation with the view of the camera will appear.

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
major

Tracking

(blocking-b2g:2.1+, b2g-v2.0 unaffected, b2g-v2.1 affected, b2g-v2.2 affected)

RESOLVED DUPLICATE of bug 1099023
blocking-b2g 2.1+
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.1 --- affected
b2g-v2.2 --- affected

People

(Reporter: SalvadorR, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [2.1-exploratory-3][blocking][tef-triage])

Attachments

(2 files)

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
Flags: needinfo?(jmitchell)
Attached image greynotifcation.png
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
QA Whiteboard: [QAnalyst-Triage?]
[Blocking Requested - why for this release]: Regression, unusual / unexpected functionality, poor UX
blocking-b2g: --- → 2.1?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
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.
blocking-b2g: 2.1? → 2.1+
Flags: needinfo?(sescalante)
QA Contact: jmercado
Severity: normal → major
Whiteboard: [2.1-exploratory-3] → [2.1-exploratory-3][blocking][tef-triage]
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Broken by Bug 927862 - can you take a look?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(alive)
QA Contact: jmercado
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.
Flags: needinfo?(alive)
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.
Flags: needinfo?(ferjmoreno)
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.
Flags: needinfo?(ferjmoreno) → needinfo?(oteo)
Borja,can you have a look at it?
Flags: needinfo?(oteo) → needinfo?(borja.bugzilla)
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!
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(sescalante)
Flags: needinfo?(mbarone976)
Flags: needinfo?(borja.bugzilla)
Resolution: --- → DUPLICATE
Duplicate of bug: 1099023
Yes, I can reproduce this. Not sure if this is the expected behavior for 2.1 and higher or is a bug.
Flags: needinfo?(mbarone976)
(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?
Flags: needinfo?(apastor)
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!
Flags: needinfo?(apastor) → needinfo?(alive)
(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.
Flags: needinfo?(alive)
You need to log in before you can comment on or make changes to this bug.