Closed Bug 1084060 Opened 10 years ago Closed 10 years ago

[Window Management] Tapping on the Camera is recording notification, opens up the download system update window

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

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

VERIFIED FIXED
2.1 S7 (24Oct)
blocking-b2g 2.1+
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.1 --- verified
b2g-v2.2 --- unaffected

People

(Reporter: KTucker, Assigned: gmarty)

References

()

Details

(Keywords: regression, Whiteboard: [2.1-flame-test-run-3], [systemsfe])

Attachments

(2 files)

Description:
If the user starts recording a video, pulls down the status bar and taps on the "Camera & Mic are ON" notification, the system update download window will open up. 

Prerequisite: A system update notification is in the status bar. 

Repro Steps:
1)  Updated Flame to Build ID: 20141015001201
2)  Tap on the camera app.
3)  Switch to the camcorder and start recording a video.
4)  Pull down the notification tray and tap on the "Camera - Camera & Mic are ON" notification. 

Actual:
The user is taken to the "System Update" download window. 

Expected:
The user is returned to the camera app. 

Environmental Variables
Device: Flame 2.1(KK)(319mb)(Full Flash)
Build ID: 20141015001201
Gecko: https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/4853208cb48a
Gaia: 379ea4c9dd6d3f8ca2f79ce59c15f6afe6e557c3
Platform Version: 34.0
Firmware Version: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Repro frequency: 100%
Link to failed test case: Found during exploratory testing. 
See attached: video clip, logcat
Youtube: http://youtu.be/OdpkxGcoWGI
This issue does not occur on Flame 2.2 and Flame 2.0

Nothing happens when the user taps on the "Camera - Camera & Mic are ON" notification. 

Flame 2.2 

Device: Flame 2.2 Master KK (319mb) (Full Flash)
Build ID: 20141015040201
Gaia: 5f1f0960ae9d22acf2a324ad37a48174d6df87f6
Gecko: 62f0b771583c
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 36.0a1 (Master)
Firmware Version: v180
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Flame 2.0

Environmental Variables:
Device: Flame 2.0 KK (319mb) (Full Flash)
Build ID: 20141015000206
Gaia: c6c6116ca225c2c934220ae6867e5a3256d65e00
Gecko: 24a2aa6bf1c4
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 32.0 (2.0)
Firmware Version: v180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: regression
[Blocking Requested - why for this release]:

A bit of an odd user-path but some very odd behavior + this is a regression
blocking-b2g: --- → 2.1?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
regression window won't be available - this is due to "Prerequisite: A system update notification is in the status bar." making this bug only able to be repro'd on full-flash which is not viable for our regression-window builds archive.  :/
The sounds very bizarre to me and something we don't want to ship with.

:gwagner, can you help with input/assignee ?
Flags: needinfo?(anygregor)
(In reply to Joshua Mitchell [:Joshua_M] from comment #3)
> regression window won't be available - this is due to "Prerequisite: A
> system update notification is in the status bar." making this bug only able
> to be repro'd on full-flash which is not viable for our regression-window
> builds archive.  :/

Can you elaborate more here? We should always get the upgrade notification when we have an old build.

I don't think I can reproduce on my 2.1 build. I tried it a few times and it seems that it triggers the upgrade notification when you touch the upgrade-notification slightly.
Can we try to reproduce with a touch-pen so we are sure we are only hitting the video notification?
Flags: needinfo?(anygregor) → needinfo?(jmitchell)
Keywords: qawanted
QA Contact: ckreinbring
Reverse regression window
Last broken
BuildID: 20141013135906
Gaia: 2a536e4df82410178d8440cc710d8f838a95a0b9
Gecko: 9bfd8ab6b440
Platform Version: 36.0a1
Firmware Version: V180
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

First working
BuildID: 20141013180702
Gaia: 4f86c631e0465c0e56ccebeb1324fd28be9ea32f
Gecko: c7f5a7b46fcd
Platform Version: 36.0a1
Firmware Version: V180
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Working Gaia / Broken Gecko = No repro
Gaia: 4f86c631e0465c0e56ccebeb1324fd28be9ea32f
Gecko: 9bfd8ab6b440
Broken Gaia / Working Gecko = Repro
Gaia: 2a536e4df82410178d8440cc710d8f838a95a0b9
Gecko: c7f5a7b46fcd
Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/2a536e4df82410178d8440cc710d8f838a95a0b9...4f86c631e0465c0e56ccebeb1324fd28be9ea32f

B2G Inbound
Last broken
BuildID: 20141013082253
Gaia: 83779ff088c794606c00f98851ada88402cb55dd
Gecko: 3f844c63335f
Platform Version: 35.0a1
Firmware Version: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

First working
BuildID: 20141013092306
Gaia: ba6667c83c5d0fb1e333349dfeaf5f6ca8043e63
Gecko: 276e5f3aecbc
Platform Version: 35.0a1
Firmware Version: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Working Gaia / Broken Gecko = No repro
Gaia: ba6667c83c5d0fb1e333349dfeaf5f6ca8043e63
Gecko: 3f844c63335f
Broken Gaia / Working Gecko = Repro
Gaia: 83779ff088c794606c00f98851ada88402cb55dd
Gecko: 276e5f3aecbc
Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/83779ff088c794606c00f98851ada88402cb55dd...ba6667c83c5d0fb1e333349dfeaf5f6ca8043e63
QA Whiteboard: [QAnalyst-Triage?]
Keywords: qawanted
This issue was fixed in 2.2 by bug 1061969 - but it did not get into the 2.1 branch - can you take a look Vivien?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(21)
Uplifting bug 1061969 is probably too risky at this point. I think we will need a one-off fix for 2.1 here.

Guillaume, can you take a look?
Flags: needinfo?(21) → needinfo?(gmarty)
Regression
Assignee: nobody → gmarty
blocking-b2g: 2.1? → 2.1+
Attached file Github PR
I took the Gaia bit from Bug 1061969 for this PR. So technically it is an uplift of 1061969.
The utility tray works as smoothly as on master (yay!) and the bug described here is fixed.

Tests are green locally but let's see what gaia-try thinks of it.
Flags: needinfo?(gmarty)
Target Milestone: --- → 2.1 S7 (24Oct)
Discussed with Guillaume about this offline. We are going to try and come up with a less risky patch for 2.1 here.
Attached file Github PR quick fix
Here is a quick fix for this issue. Etienne will review it.

I leave the other patch open here in case we decide to go ahead and land it later.
Attachment #8509364 - Flags: review?(etienne)
Comment on attachment 8509364 [details] [review]
Github PR quick fix

small nit on github
Attachment #8509364 - Flags: review?(etienne) → review+
Landed in v2.1 branch in https://github.com/mozilla-b2g/gaia/commit/07cd1562b90960a343104a67b184cf9e01bee8a0
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
This issue is verified fixed on Flame 2.1.

Result: Nothing happens when the user taps on the "Camera - Camera & Mic are ON" notification. 
  
Flame 2.1

Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141027001201
Gaia: c97463d61f45513a2123b19610386ddbfc916819
Gecko: 4f8c0c021128
Gonk: 6e51d9216901d39d192d9e6dd86a5e15b0641a89
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: