[Aries KK][Camera] The screen will be locked automatically after timeout, when you are recording.

VERIFIED FIXED in Firefox 44, Firefox OS master

Status

()

Core
Audio/Video: MediaStreamGraph
P2
normal
VERIFIED FIXED
2 years ago
2 years ago

People

(Reporter: Jessica, Assigned: pehrsons)

Tracking

({regression})

unspecified
mozilla44
ARM
Gonk (Firefox OS)
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.5+, firefox44 fixed, b2g-master verified)

Details

(Whiteboard: [2.5-aries-test-run-3])

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(5 attachments)

(Reporter)

Description

2 years ago
Created attachment 8671269 [details]
logcat_1652.txt

[1.Description]:
[Aries KK v2.5][Camera] The screen will be locked automatically after timeout, even if you are recording.
Time: 16:52
See attachments: logcat_1652.txt and Aries_KK v2.5.3gp

[2.Testing Steps]: 
Precondition: "Screen Timeout" is 1 minute.
1.Launch camera app.
2.Switch to video mode.
3.Tap the recording icon.

[3.Expected Result]: 
3.The screen shouldn't be locked automatically after 1minute.

[4.Actual Result]: 
3.The screen will be locked automatically after 1minute.

[5.Reproduction build]: 
Device: Aries KK 2.5 (Affected)
Build ID               20151008002716
Gaia Revision          b99837aa2294348317bcae68acabe71d9a83d774
Gaia Date              2015-10-07 13:04:16
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/c6ede6f30f3dc886543bb1c76fd7c8b5a151786b
Gecko Version          44.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20151007.234555
Firmware Date          Wed Oct  7 23:46:03 UTC 2015
Bootloader             s1

Device: Flame KK 2.5 (Unaffected)
Build ID               20151007150205
Gaia Revision          b99837aa2294348317bcae68acabe71d9a83d774
Gaia Date              2015-10-07 13:04:16
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/1e1fa696e2b626ead6817b7c5bd871fec5d5ab5a
Gecko Version          44.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20151007.183338
Firmware Date          Wed Oct  7 18:33:51 EDT 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

Device: Flame KK 2.2 (Unaffected)
Build ID               20151007032507
Gaia Revision          5dd95cfb9f1d6501ce0e34414596ef3dd9c2f583
Gaia Date              2015-09-21 11:20:23
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/b48f0cd1bc45
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20151007.064847
Firmware Date          Wed Oct  7 06:48:58 EDT 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0


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

[7.TCID]: 
Free test
(Reporter)

Comment 1

2 years ago
Created attachment 8671272 [details]
Aries_KK v2.5.3gp
(Reporter)

Updated

2 years ago
status-b2g-v2.2: --- → unaffected
status-b2g-master: --- → affected

Comment 2

2 years ago
[Blocking Requested - why for this release]:

A regression bug.
Request a regression window.

Weird... it cannot be reproduced on Flame with the same Gaia commit.
Nominate it because basic functionality is broken.
blocking-b2g: --- → 2.5?
Keywords: regression, regressionwindow-wanted
If this bug is Aries only then it has not been proven that this is a regression (within Aries). QAwanted to test on earlier Aries build(s) and see if this ever worked on Aries.
Keywords: regression, regressionwindow-wanted → qawanted
Confirmed that this issue doesn't happen on Flame. Removing 2.2 tracking flag because Flame branch checking is irrelevant to this bug.

Also confirmed that this is a regression within Aries. This issue does NOT occur on the following Aries build:

Device: Aries 2.5
BuildID: 20150603164854
Gaia: ff80db87926a5c2769e158801090465b4ed117fa
Gecko: 196d99aabc27
Gonk: 3af1ede0d0956cfbf9c549df7cd9a6807a9efdf2
Version: 41.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Working on getting the window.
status-b2g-v2.2: unaffected → ---
Flags: needinfo?(jmercado)
Keywords: qawanted → regression, regressionwindow-wanted
QA Contact: pcheng
Flags: needinfo?(jmercado)
mozilla-inbound regression window:

Last Working
Device: Aries 2.5
BuildID: 20150930082031
Gaia: 1bc0b19527777ffee494962b48db4be857b07d64
Gecko: b50322abc2863332513aa05e5e53ab3d8278672d
Version: 44.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

First Broken
Device: Aries 2.5
BuildID: 20150930081257
Gaia: 1bc0b19527777ffee494962b48db4be857b07d64
Gecko: 8ad5cb2c028d1c82708a75785c8ca0819e29aa9e
Version: 44.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Gaia is the same so it's a Gecko issue.

Gecko pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b50322abc2863332513aa05e5e53ab3d8278672d&tochange=8ad5cb2c028d1c82708a75785c8ca0819e29aa9e

This issue is caused by either Bug 1170958 or Bug 1103188. I'm putting 1170958 as the cause for now.
Blocks: 1170958
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(mshuman)
Flags: needinfo?(ktucker)
Keywords: regressionwindow-wanted
Andreas, can you take a look at this please? This might have been caused by the landing for bug 1170958 but we are not sure.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(pehrsons)

Updated

2 years ago
Flags: needinfo?(mshuman)
(Assignee)

Comment 7

2 years ago
I won't be able to test on a device until sometime next week. If you could re-run the tests with logging of nsMediaElement:5 enabled though, that could help somewhat. Thanks!

Updated

2 years ago
blocking-b2g: 2.5? → 2.5+
Priority: -- → P2

Updated

2 years ago
Component: Gaia::Camera → Audio/Video: MSG/cubeb/GMP
Product: Firefox OS → Core
Adding qawanted to check comment 7
Keywords: qawanted
Created attachment 8673336 [details]
logcat with nsMediaElement:5 enabled

Andreas,

Please see attached logcat.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado)
(Assignee)

Comment 10

2 years ago
Thanks, that was helpful indeed. Below is the heart of the problem. We do not recognize that the Camera stream has video. I'll take a look.

> 10-13 14:22:10.556 1527 1527 I PRLog : -1225785004[b6852000]: MediaElement b0afb800 Setting up playback of DOMMediaStream afc6e6c0
> 10-13 14:22:10.566 296 1727 D mm-camera-intf: mm_stream_read_msm_frame: VIDIOC_DQBUF buf_index 2, frame_idx 3, stream type 1
> 10-13 14:22:10.566 296 1727 D mm-camera-intf: mm_stream_read_msm_frame: VIDIOC_DQBUF buf_index 2, frame_idx 3, stream type 4
> 10-13 14:22:10.566 399 1707 D mm-camera: mct_pipeline_process_set:command=800000e
> 10-13 14:22:10.566 399 1707 D mm-camera: mct_pipeline_send_ctrl_events: Send Set Parm events
> 10-13 14:22:10.566 1527 1527 I PRLog : -1225785004[b6852000]: b0afb800 Network state changed to IDLE
> 10-13 14:22:10.566 1527 1527 I PRLog : -1225785004[b6852000]: b0afb800 ChangeDelayLoadStatus(0) doc=0xb294ca00
> 10-13 14:22:10.566 1527 1527 I PRLog : -1225785004[b6852000]: MediaElement b0afb800 MediaStream tracks available
> 10-13 14:22:10.566 1527 1527 I PRLog : -1225785004[b6852000]: MediaElement b0afb800 UpdateReadyStateInternal() Stream with no tracks
Assignee: nobody → pehrsons
Status: NEW → ASSIGNED
Flags: needinfo?(pehrsons)
(Assignee)

Comment 11

2 years ago
Created attachment 8673514 [details]
MozReview Request: Bug 1212783 - Expose TrackPort in DOMMediaStream.h r=roc

Bug 1212783 - Expose TrackPort in DOMMediaStream.h r?roc
(Assignee)

Comment 12

2 years ago
Created attachment 8673515 [details]
MozReview Request: Bug 1212783 - Add a MediaStreamTrack to DOMCameraControl. r=aosmond

Bug 1212783 - Add a MediaStreamTrack to DOMCameraControl. r?aosmond
Without this, HTMLMediaElement cannot see that the camera stream contains
video so it won't hold the screen wake lock.
(Assignee)

Comment 13

2 years ago
I think these patches should do it. Could you please try again?

Here's a try push that checks that I didn't break anything: https://treeherder.mozilla.org/#/jobs?repo=try&revision=bb534459b002
Keywords: qawanted
We are not set up to build Gecko patches. No-Jun, could you help getting an Aries build with those patches so we can test it? Thanks.
Flags: needinfo?(npark)
(Assignee)

Updated

2 years ago
Duplicate of this bug: 1214757
I started the taskcluster build with both of above patches applied, and the build should be available when it's done.

Link: https://tools.taskcluster.net/task-inspector/#bHAMT6kUQpyBMJe1dJjpjQ/0
Flags: needinfo?(npark)
Thank you, No-Jun. 

This issue IS still reproducing after the patches using the build from comment 16. Screen times out at 1 minute while recording. NI Andreas to take a look.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(pehrsons)
Flags: needinfo?(jmercado)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado)
Just to confirm, I built the gecko off this branch:
https://github.com/npark-mozilla/gecko-dev/tree/1212783
and the patches are shown here as commit:
https://github.com/npark-mozilla/gecko-dev/commit/96e69d1f75a2390e7ff6b73fab56980a4cd9c9d2

Let me know if I have missed anything.
(Assignee)

Comment 19

2 years ago
I just rebuilt with my patches locally and the camera app keeps the screen alive as I had hoped.

I suspect that taskcluster is not picking up your branch as you expect. It should be easy to verify with the sources.xml provided by taskcluster, but that file is private so I can't see it.
Flags: needinfo?(pehrsons) → needinfo?(npark)
(Assignee)

Comment 20

2 years ago
Comment on attachment 8673514 [details]
MozReview Request: Bug 1212783 - Expose TrackPort in DOMMediaStream.h r=roc

Bug 1212783 - Expose TrackPort in DOMMediaStream.h r?roc
Attachment #8673514 - Flags: review?(roc)
(Assignee)

Comment 21

2 years ago
Comment on attachment 8673515 [details]
MozReview Request: Bug 1212783 - Add a MediaStreamTrack to DOMCameraControl. r=aosmond

Bug 1212783 - Add a MediaStreamTrack to DOMCameraControl. r?aosmond
Without this, HTMLMediaElement cannot see that the camera stream contains
video so it won't hold the screen wake lock.
Attachment #8673515 - Flags: review?(aosmond)
(Assignee)

Comment 22

2 years ago
(In reply to Andreas Pehrson [:pehrsons] (Telenor) from comment #19)
> I just rebuilt with my patches locally and the camera app keeps the screen
> alive as I had hoped.
> 
> I suspect that taskcluster is not picking up your branch as you expect. It
> should be easy to verify with the sources.xml provided by taskcluster, but
> that file is private so I can't see it.

I Double checked the logs and it looks like my patch didn't do what I expected.

This was on a Flame, could it be holding the wake lock in some other way maybe?

I'll follow the patches through.
(Assignee)

Comment 23

2 years ago
Comment on attachment 8673515 [details]
MozReview Request: Bug 1212783 - Add a MediaStreamTrack to DOMCameraControl. r=aosmond

Bug 1212783 - Add a MediaStreamTrack to DOMCameraControl. r?aosmond

Without this, HTMLMediaElement cannot see that the camera stream contains
video so it won't hold the screen wake lock.
(Assignee)

Comment 24

2 years ago
Ok, tiny fix but looks much better now. No-Jun, could you fire up another of those builds? Thanks!
Hi Andreas, I tried to apply this patch to the latest gecko, but it is failing (both of them).  Looking at the rej file, it looks like there are some changes made to the DOMMediaStream.cpp (Especially to the TrackPort definition) and other files.  Just to be safe, could you rebase your patch and let me know?
Flags: needinfo?(npark) → needinfo?(pehrsons)
(Assignee)

Comment 26

2 years ago
I can do that tomorrow.

Alternatively you can sync to the exact revision my patches have with mercurial (see the commands on reviewboard) and build a slightly older version than the current m-c.
Comment on attachment 8673514 [details]
MozReview Request: Bug 1212783 - Expose TrackPort in DOMMediaStream.h r=roc

https://reviewboard.mozilla.org/r/21941/#review20207

::: dom/media/DOMMediaStream.h:236
(Diff revision 1)
> +      EXTERNAL

Document these
Attachment #8673514 - Flags: review?(roc) → review+
Comment on attachment 8673515 [details]
MozReview Request: Bug 1212783 - Add a MediaStreamTrack to DOMCameraControl. r=aosmond

https://reviewboard.mozilla.org/r/21943/#review20265
Attachment #8673515 - Flags: review?(aosmond) → review+
Actually, I have diffed your new patch, and seemed that the change was small (one line) so I modified it manually and reran the build.

https://tools.taskcluster.net/task-inspector/#SSWzgMjdSA-NSfS380MAQg/0

Adding qawanted to check on this build.

Just to be clear, following line was the difference:
175c175
< @@ -470,16 +519,29 @@ nsDOMCameraControl::Get(uint32_t aKey, n
---
> @@ -470,16 +519,28 @@ nsDOMCameraControl::Get(uint32_t aKey, n
194d193
< +  NotifyTrackAdded(track);
Keywords: qawanted
Thanks No Jun for following up with the build.

The build created at comment 29 does NOT reproduce the bug. Screen does not time out at 1 minute into recording. Bug repro rate: 0 out of 5. Looks good to land.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado)
(Assignee)

Comment 31

2 years ago
Great, thanks!
Flags: needinfo?(pehrsons)
(Assignee)

Updated

2 years ago
Attachment #8673514 - Attachment description: MozReview Request: Bug 1212783 - Expose TrackPort in DOMMediaStream.h r?roc → MozReview Request: Bug 1212783 - Expose TrackPort in DOMMediaStream.h r=roc
(Assignee)

Comment 32

2 years ago
Comment on attachment 8673514 [details]
MozReview Request: Bug 1212783 - Expose TrackPort in DOMMediaStream.h r=roc

Bug 1212783 - Expose TrackPort in DOMMediaStream.h r=roc
(Assignee)

Comment 33

2 years ago
Comment on attachment 8673515 [details]
MozReview Request: Bug 1212783 - Add a MediaStreamTrack to DOMCameraControl. r=aosmond

Bug 1212783 - Add a MediaStreamTrack to DOMCameraControl. r=aosmond
Without this, HTMLMediaElement cannot see that the camera stream contains
video so it won't hold the screen wake lock.
Attachment #8673515 - Attachment description: MozReview Request: Bug 1212783 - Add a MediaStreamTrack to DOMCameraControl. r?aosmond → MozReview Request: Bug 1212783 - Add a MediaStreamTrack to DOMCameraControl. r=aosmond

Comment 35

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/34f53b05a578
https://hg.mozilla.org/mozilla-central/rev/cfd7882e6f70
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox44: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
This issue is verified fixed in Aries 2.5 and Flame 2.5.

Environmental Variables:
Device: Aries 2.5 [Full Flash]
BuildID: 20151026111709
Gaia: a677ddd3aa3a81058775938bd56008d96dbc78b0
Gecko: 5ca03a00d26823ce91ee0eaa2937bed605bd53c1
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 44.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Device: Flame 2.5 [Full Flash]
BuildID: 20151026030217
Gaia: a677ddd3aa3a81058775938bd56008d96dbc78b0
Gecko: 5ca03a00d26823ce91ee0eaa2937bed605bd53c1
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 44.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Result:
Screen doesn't time out while recording a video.
Status: RESOLVED → VERIFIED
status-b2g-master: affected → verified
Flags: needinfo?(jmercado)
Flags: needinfo?(jmercado)

Updated

2 years ago
Depends on: 1232602
You need to log in before you can comment on or make changes to this bug.