1202967 - [AriesKK]Screen will be freezed if you launch camera by pressing HW camera key in Recent View.

Status: VERIFIED FIXED

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

Description

[zouyi(Leave from Mozilla)]

Attachment: logcat.txt

[1.Description]:
[AriesKK v2.5][Camera]Screen will be freezed if you launch camera by pressing HW camera key in Recent View.
See attachment: AriesKK_V2.5.3gp and logcat.txt
Found at: 23:19

[2.Testing Steps]: 
1. Long tap home button;
2. Long press HW Camera key

[3.Expected Result]: 
2. Camera can work normally.

[4.Actual Result]: 
2. Screen is freezed untill you tap home button to exit.

[5.Reproduction build]: 
Device: Aries KK v2.5(Affected)
Build ID               20150909010033
Gaia Revision          e69f2c86b931b723dd405115e33a1d02e6c5f5e6
Gaia Date              2015-09-08 20:39:40
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/a4f512250d7d6199ae8c39eafdb3a2d8977a7dc4
Gecko Version          43.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20150909.002137
Firmware Date          Wed Sep  9 00:21:45 UTC 2015
Bootloader             s1

[6.Reproduction Frequency]: 
Always Recurrence,5/5

[7.TCID]: 
Free Test

[8. Note]:
HW Camera key is not supported by Flame

Comment 1

[zouyi(Leave from Mozilla)]

Attachment: AriesKK_V2.5.3gp

Comment 2

[Norry.L.F(Leave from Mozilla)]

Hi No-Jun,

Could you help to dispatch the bug? thanks :)

Comment 3

[No-Jun Park [:njpark]]

[Blocking Requested - why for this release]:

Hmm, if it freezes the device that easily, then I would assume this is a blocker for 2.5.  I suppose we do support the camera button

Comment 4

[Mahendra Potharaju [:mahe]]

Blocks 2.5. P2 priority

Comment 5

[Hema Koka [:hema]]

Andrew, 

Can you take up the initial investigation for this issue?

Thanks
Hema

Comment 6

[Andrew Osmond [:aosmond] (he/him)]

Reproducing this, it appears only the viewfinder is stuck. You can take pictures (and the thumbnail appears), auto focus, touch-to-focus, etc. Viewing a taken picture causes the viewfinder to match the picture (but still frozen) when exiting the preview gallery.

Comment 7

[Andrew Osmond [:aosmond] (he/him)]

The gecko preview is running fine. It appears to be related to the video element state.

In a normal app launch, we see that while the video element may become paused during startup, it will become unpaused after configuration is complete:

09-14 14:42:35.330  1783  1783 I PRLog   : -1225465516[b6852000]: b1910000 SuspendOrResumeElement(pause=1, suspendEvents=0) hidden=0
09-14 14:42:35.370  1783  1783 I Camera  : Content JS LOG: camera  configuration success  +43ms
09-14 14:42:35.370  1783  1783 I Camera  : Content JS LOG: controller:viewfinder  configuring  +8ms
09-14 14:42:35.370  1783  1783 I Camera  : Content JS LOG: camera  loading stream into element  +1ms
09-14 14:42:35.380  1783  1783 I Camera  : Content JS LOG: camera  camera didn't change  +1ms
09-14 14:42:35.380  1783  1783 I Camera  : Content JS LOG: controller:viewfinder  stream started  +2ms
09-14 14:42:35.430  1783  1783 I Camera  : Content JS LOG: controller:activity  configured mode  +1ms picture,video
09-14 14:42:35.490  1783  1783 I PRLog   : -1225465516[b6852000]: b1910000 SuspendOrResumeElement(pause=0, suspendEvents=0) hidden=0

With this bug's STR, the video element never gets unpaused:

09-14 14:37:33.100  1557  1557 I PRLog   : -1225465516[b6852000]: b2855400 SuspendOrResumeElement(pause=1, suspendEvents=0) hidden=0
09-14 14:37:33.180  1557  1557 I Camera  : Content JS LOG: camera  configuration success  +44ms
09-14 14:37:33.190  1557  1557 I Camera  : Content JS LOG: controller:viewfinder  configuring  +15ms
09-14 14:37:33.200  1557  1557 I Camera  : Content JS LOG: camera  loading stream into element  +4ms
09-14 14:37:33.200  1557  1557 I Camera  : Content JS LOG: camera  camera didn't change  +1ms
09-14 14:37:33.200  1557  1557 I Camera  : Content JS LOG: controller:viewfinder  stream started  +2ms
09-14 14:37:33.260  1557  1557 I Camera  : Content JS LOG: controller:activity  configured mode  +1ms picture,video
09-14 14:37:33.260  1557  1557 I PRLog   : -1225465516[b6852000]: b2855400 SuspendOrResumeElement(pause=1, suspendEvents=0) hidden=0

Comment 8

[Andrew Osmond [:aosmond] (he/him)]

When the window volume changes between muted and unmuted, this can change the state of the video element between paused and unpaused respectively. It seems the window volume is muted in the STR case as evidenced by the "mozinterruptbegin" event dispatched by the video element (that is the only case it is issued).

09-14 14:37:33.100  1557  1557 I PRLog   : -1225465516[b6852000]: b2855400 Queuing event mozinterruptbegin
09-14 14:37:33.100  1557  1557 I PRLog   : -1225465516[b6852000]: b2855400 SuspendOrResumeElement(pause=1, suspendEvents=0) hidden=0

App sounds (shutter, recording start/stop) are still heard. Recorded videos can be played back (with sound) in the preview gallery. One possible solution is to ensure that when the camera preview stream is loaded into video element, we mark it as having no audio component (which we used to do in Gecko I thought...) so that it doesn't pause due to audio changes. However it does leave the question of how the element got into the muted state in the first place.

Comment 9

[Andrew Osmond [:aosmond] (he/him)]

As it turns out, the camera preview media stream *does not* have an audio track. But HTMLMediaElement will stop playing regardless if it is muted. The interactions with the audio channel agent are not obvious to me (e.g. why do we trigger the agent at all if we don't have an audio track...) so someone on the DOM side should take a look at this point.

Comment 10

[Blake Wu [:bwu][:blakewu]]

Alastor, 
Per comment 8 and 9, it seems related to audio channel, can you have a look?

Comment 11

[Alastor Wu [:alwu]]

I'll investigate it later.

Comment 12

[Alastor Wu [:alwu]]

Attachment: Log : mute preview video

Hi, Even,
Could you help to take a look to this issue?
From the log, we can see that the system app muted the MediaElement when it get the "activestatechanged". 
The system app should unmute MediaElement, but it didn't.
Thanks!

Comment 13

[Evan Tseng [:evanxd]]

Alastor, I'll investigate this later.

Comment 14

[Evan Tseng [:evanxd]]

Cannot reproduce in the below build.

Build ID               20150812231434
Gaia Revision          52f3ea58df38e5427f6afeb636bc6ad01d24022f
Gaia Date              2015-08-12 16:40:43
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/7649ffe28b67aa2dad0f67ea01500c0ff91b2bac
Gecko Version          43.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20150619.224059
Firmware Date          Fri Jun 19 22:41:08 UTC 2015
Bootloader             s1

Will use the build in [1](Comment 0) to investigate.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1202967#c0

Comment 15

[Evan Tseng [:evanxd]]

Can reproduce in the build in Comment 0.
Investigate...

Comment 16

[Evan Tseng [:evanxd]]

The root cause is about HierarchyManager. `HierarchyManager.getTopMostWindow()`[1] will get `undefined` in `HierarchyManager.updateTopMostWindow()` method[2] after long tap home button and long press HW Camera key. Then the `topmostwindowchanged` will not be sent from [3]. It means that System app will think no any window in foreground. But actually the Camera window is foreground.

Because of the above reason, Audio Channel Service[4] will think the Camera window is in background. So it cannot be played. Then the screen is freezed.

We need to fix this bug from HierarchyManager.

Luke will investigate this. Thanks a lot.

[1]: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/hierarchy_manager.js#L40
[2]: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/hierarchy_manager.js#L148
[3]: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/hierarchy_manager.js#L152
[4]: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/audio_channel_service.js

Comment 17

[Luke Chang [:lchang] (inactive)]

Sorry to steal it from Alastor because it may be fixed from Gaia side.

The cause is, if TaskManager is closed because of activity window (in this case, launching camera app by HW button), it won't hide until the activity app window is fully opened. Thus, HierarchyManager will always get "undefined" when calling "getTopMostWindow" at "windowopened" stage since TaskManager is still active at that moment and there's no "TopMostWindow" defined for sure.

To fix it, I force HierarchyManager to update the TopMostWindow again after TaskManager is closed and it looks good now. I'll upload my patch later.

Comment 18

[GitHub Autolander Bot]

Attachment: [gaia] luke-chang:1202967_camera_freeze > mozilla-b2g:master

Comment 19

[Luke Chang [:lchang] (inactive)]

Comment on attachment 8666727 [details] [review]
[gaia] luke-chang:1202967_camera_freeze > mozilla-b2g:master

Hi Tim,

Could you take a look at this? Thanks a lot.

Comment 20

[Luke Chang [:lchang] (inactive)]

Tim, Thanks a lot.


test passed: https://treeherder.mozilla.org/#/jobs?repo=gaia&revision=968a54ab0a2046d22d7605c2d37739a0c7b02723

landed on master: https://github.com/mozilla-b2g/gaia/commit/28b0f9fb59e7659e3717fa9936076041225e5f2a

Comment 21

[Evan Tseng [:evanxd]]

Thanks, Luke.

Comment 22

[Jessica]

Attachment: verified_Aries KK v2.5.3gp

According to the STR of Comment 0, this bug has been verified as pass on latest Aries KK v2.5.
Actual results: Camera can work normally.
See attachment: verified_Aries KK v2.5.3gp
Reproduce rate: 0/6

Device: Aries KK v2.5 (Pass)
Build ID               20151008233852
Gaia Revision          e698df503ff700eb5782e3d50c6eb753567d3451
Gaia Date              2015-10-08 17:26:52
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/23b7f289df923c01e692299fcd4be7029de8b155
Gecko Version          44.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20151008.225742
Firmware Date          Thu Oct  8 22:57:51 UTC 2015
Bootloader             s1