1110102 - [v2.2] Add test to verify that the video recording stops immediately when going to homescreen

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::UI Tests, defect)

Description

[Robert Chira [:RobertC]]

https://moztrap.mozilla.org/manage/case/14447

Video recording should stop immediately when the user returns to the homescreen.

Please see this issue:

https://bugzilla.mozilla.org/show_bug.cgi?id=1051172

    Launch Camera and switch to camcorder.

    Press home key when it reaches 10 seconds.

    Go to Gallery and play the recorded video and observe that video will be played for 15 seconds.

    The video should stop recording immediately once the user goes to the homescreen.

Comment 1

[Robert Chira [:RobertC]]

Attachment: Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/26844

http://jenkins1.qa.scl3.mozilla.com/view/UI/job/flame-kk.ui.adhoc/451/console

Comment 2

[Johan Lorenzo [:jlorenzo]]

Comment on attachment 8537737 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/26844

That's a great pull to me. I think we can make the test more readable by moving the conversion to seconds in the Page class. What do you think about it?

Comment 3

[Robert Chira [:RobertC]]

Johan, I left a reply to you comment in the PR. I would prefer to leave the conversions in the test since other tests expect the timer in time() format.

Also I am investigating the failures from the adhoc.

Comment 4

[Robert Chira [:RobertC]]

The test failed twice in the adhoc because the duration of the recording is longer the expected.
Between the tap on the record and the tap on the home button there is a 5 second hard-coded sleep.

I noticed that when manually reproducing the steps from comment 0 it takes some time for the camera app to close, which might explain the 7 seconds of recording instead of 5 in one of the failures.

My concern is with the failure where it recorded 10 seconds instead of 5. I will investigate this issue further.

Are there any known performance issues with the camera app when trying to close it while a recording is active? Is there an approximate amount of time in which the app is expected to close?

Comment 5

[Wilson Page [:wilsonpage]]

As soon as the app is hidden/closed we make the request to `stopRecording()` [1][2]. Sounds like there may be a delay on the Gecko side before this request is actually fulfilled. :mikeh or :aosmand may know more.

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/camera/js/controllers/camera.js#L78
[2] https://github.com/mozilla-b2g/gaia/blob/master/apps/camera/js/lib/camera/camera.js#L378

Comment 6

[Johan Lorenzo [:jlorenzo]]

Comment on attachment 8537737 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/26844

Clearing the reviews while the investigation is ongoing.

Comment 7

[Robert Chira [:RobertC]]

I tried different methods to improve the stability of the test with no success.
The failure rate is 5 out of 10.

The margin of error in the test is set to 2 seconds (if we tap on the home button when the timer in the camera app is at 5 seconds the resulting video should not be longer the 7 seconds). While running the test I got videos that where up to and including 12 seconds long.

No-Jun, do you know of any issues in that area of the app or with that action specifically (tapping on home button while recording is in progress)? The videos that are 5+ seconds longer then intended are a concern. Maybe you can take a look over my patch in case I made any errors.

For now I will move the task back to the backlog.

Comment 8

[No-Jun Park [:njpark]]

(In reply to Robert Chira [:RobertC] from comment #7)
> I tried different methods to improve the stability of the test with no
> success.
> The failure rate is 5 out of 10.
> 
> The margin of error in the test is set to 2 seconds (if we tap on the home
> button when the timer in the camera app is at 5 seconds the resulting video
> should not be longer the 7 seconds). While running the test I got videos
> that where up to and including 12 seconds long.
> 
> No-Jun, do you know of any issues in that area of the app or with that
> action specifically (tapping on home button while recording is in progress)?
> The videos that are 5+ seconds longer then intended are a concern. Maybe you
> can take a look over my patch in case I made any errors.
> 
> For now I will move the task back to the backlog.

I think I heard about the extra seconds of recording, but I did not know it was hardcoded. I'll needinfo mikeh since he can explain the delay between the home button tap and recording process termination.

Comment 9

[Mike Habicher [:mikeh] (high bugzilla latency)]

The hardcoded delay is at the -beginning- of recording, to allow the audible start-recording indicator to finish. There is no hardcoded delay at the end.

As Wilson points out in comment 5, the Camera app calls stopRecording() as soon as it gets a visibility-change notification, and the camera stack should respond to it very quickly (I'll confirm that). The delay is very likely in the system getting that visibility-change message to the app.

IIRC, backgrounding an app drops its priority significantly, so that's probably not helping.

Alive, any thoughts? I think this issue should move to System::WindowMgmt.

Comment 10

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

(In reply to Mike Habicher [:mikeh] from comment #9)
> The hardcoded delay is at the -beginning- of recording, to allow the audible
> start-recording indicator to finish. There is no hardcoded delay at the end.
> 
> As Wilson points out in comment 5, the Camera app calls stopRecording() as
> soon as it gets a visibility-change notification, and the camera stack
> should respond to it very quickly (I'll confirm that). The delay is very
> likely in the system getting that visibility-change message to the app.
> 
> IIRC, backgrounding an app drops its priority significantly, so that's
> probably not helping.
> 
> Alive, any thoughts? I think this issue should move to System::WindowMgmt.

Delayed visibilitychange notifying is a known issue and we have no way to fix it until bug 1034001 is fixed.

Comment 11

[BMO Automation]

Firefox OS is not being worked on