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

RESOLVED WONTFIX

Status

Firefox OS
Gaia::UI Tests
RESOLVED WONTFIX
3 years ago
2 months ago

People

(Reporter: RobertC, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
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.
(Reporter)

Updated

3 years ago
QA Whiteboard: [fxosqa-auto-s6]
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?
(Reporter)

Comment 3

3 years ago
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.
(Reporter)

Comment 4

3 years ago
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?
Flags: needinfo?(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
Flags: needinfo?(wilsonpage)
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.
Attachment #8537737 - Flags: review?(jlorenzo)
Attachment #8537737 - Flags: review?(florin.strugariu)
(Reporter)

Updated

3 years ago
QA Whiteboard: [fxosqa-auto-s6] → [fxosqa-auto-from-s6] [fxosqa-auto-s7]
(Reporter)

Comment 7

3 years ago
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.
Flags: needinfo?(npark)
(Reporter)

Updated

3 years ago
QA Whiteboard: [fxosqa-auto-from-s6] [fxosqa-auto-s7] → [fxosqa-auto-from-s6] [fxosqa-auto-dropped-s7] [fxosqa-auto-backlog+]
(Reporter)

Updated

3 years ago
Assignee: robert.chira → nobody
(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.
Flags: needinfo?(npark) → needinfo?(mhabicher)
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.
Flags: needinfo?(mhabicher) → needinfo?(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.
Flags: needinfo?(alive)

Comment 11

2 months ago
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.