Closed
Bug 891507
Opened 12 years ago
Closed 12 years ago
[B2G][Camera] Videos recorded in passcoded-lockscreen camera do not appear in filmstrip/Gallery
Categories
(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)
Tracking
(blocking-b2g:leo+, b2g18 verified)
People
(Reporter: ckreinbring, Assigned: mikeh)
References
Details
(Keywords: regression, smoketest)
Attachments
(1 file)
212.54 KB,
text/plain
|
Details |
Description:
A user with a lock screen passcode set up cannot create videos if they launch the camera app from the lock screen.
Repro Steps:
1) Updated to Leo Build ID: 20130709070206
2) Set up a phone lock passcode if one is not already set up.
3) Press the phone power button twice to bring up the lock screen.
4) Tap the Camera button to launch the app.
5) Tap the video camera icon, then tap it again to begin recording.
6) After a short while, tap the Stop button and observe the device's reaction.
Actual:
The recording ends but the created video is not saved.
Expected:
The created video is saved to the gallery, with a thumbnail showing briefly at the top of the screen allowing the user to preview the video immediately.
Environmental Variables
Occurs on Leo 1.1 commercial RIL
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/f917f3fb17ab
Gaia: e251ee6bdab13d8620afa8f9c2d5f14e5e6a4f99
Platform Version: 18.1
RIL Version: 01.01.00.019.152
Notes:
Repro frequency: 100%
Q Analysts Team Priority: Pri 2
See attached logcat logs
Comment 1•12 years ago
|
||
Video camera functionality is effectively disabled if using the camera app from the lock screen.
Recommend escalation to Pri 2
blocking-b2g: --- → leo?
Comment 2•12 years ago
|
||
ckreinbring, can you find the first build in which this regressed? We're assuming it was very recently, since this was found during smoketests.
Assignee: nobody → hkoka
blocking-b2g: leo? → leo+
Flags: needinfo?(ckreinbring)
Keywords: regressionwindow-wanted
Updated•12 years ago
|
Keywords: regression
Comment 3•12 years ago
|
||
Leo device, using:
Gecko http://hg.mozilla.org/releases/mozilla-b2g18/rev/f917f3fb17ab
Gaia e251ee6bdab13d8620afa8f9c2d5f14e5e6a4f99
BuildID 20130709070206
Version 18.0
I was able to record a video and I don't see it in the Gallery, but it does show in the video player.
Reporter | ||
Comment 4•12 years ago
|
||
I was also able to see the videos in the Video app. For the regression, we were able to repro the defect on the June 10 build, but we'll need to do some work on any older builds. Would you like us to go further back?
Finally, we tried on a 1.0.1 build and the bug did not repro.
Flags: needinfo?(ckreinbring)
Comment 5•12 years ago
|
||
Yes, we need to find the exact build that this started on.
(In reply to ckreinbring from comment #4)
> I was also able to see the videos in the Video app. For the regression, we
> were able to repro the defect on the June 10 build, but we'll need to do
> some work on any older builds. Would you like us to go further back?
>
> Finally, we tried on a 1.0.1 build and the bug did not repro.
Flags: needinfo?(ckreinbring)
Updated•12 years ago
|
QA Contact: cschmoeckel
Updated•12 years ago
|
QA Contact: cschmoeckel
Assignee | ||
Comment 6•12 years ago
|
||
This also happens on Inari:
- gecko: b2g18:45507bc2bea1
- gaia: v1-train:7c40bdaeaffae708342fc773926dcfac5389348e
Observed: video recorded using passcoded-lockscreen camera doesn't appear in the filmstrip or (later) in the Gallery, but does appear in the Video app.
Summary: [B2G] [Leo] [Camera] Videos are not saved if camera is launched from lock screen with a passcode → [B2G][Camera] Videos recorded in passcoded-lockscreen camera do not appear in filmstrip/Gallery
Assignee | ||
Comment 7•12 years ago
|
||
We send a 'file-watcher-notify' message when recording is stopped[1] to let DeviceStorage know that the video file is committed.
1. http://mxr.mozilla.org/mozilla-b2g18/source/dom/camera/GonkCameraControl.cpp#965
Comment 8•12 years ago
|
||
Marcia,
Rolled all the way back to a build from May 13th and not seeing this occur.
As far as I know, every other build between then and now either has a blocking issue of some sort, or has this issue repro.
Environmental Variables:
Build ID: 20130513070206
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/50726fbdc25e
Gaia: a503d9a1d0a588f3689243c1ddc0f016ede51b9d
Platform Version: 18.0
RIL Version: 01.01.00.019.093
Flags: needinfo?(ckreinbring)
Assignee | ||
Comment 9•12 years ago
|
||
Here's something else I noticed, STR:
0. enable lockscreen with a passcode and lock device
1. press Power button to wake up device
2. swipe up to unlock
3. press the Camera button to switch to the camera
4. when the Camera starts, press Mode button to switch to video
5. press the Record button; record something like a 10-second video
6. press the Stop button
7. press the Home button to return to the lockscreen
Observe: the camera-recording indicator is visible on the status bar at the top of the screen, and is red!
The recording indicator is controlled through observer notifications[1], just like the DeviceStorage notification in comment 7.
Is it possible that within the regression window, observers broke?
Comment 10•12 years ago
|
||
Mike: See Bug 828600 - this behavior has been going on for some time.
(In reply to Mike Habicher [:mikeh] from comment #9)
[snip]
Assignee | ||
Comment 11•12 years ago
|
||
(In reply to Marcia Knous [:marcia] from comment #10)
>
> Mike: See Bug 828600 - this behavior has been going on for some time.
Hmm, I remembered that bug as being a misunderstanding over how the UI was to handle the different recording events, but re-reading it now, it sounds like more than that. Thanks.
Assignee | ||
Comment 12•12 years ago
|
||
After following the steps in comment 9, if I unlock the device, open the Camera app, and try to record a video, I get a black viewfinder, and if I hit the record button, I see an error message: "Video not recorded. An error prevented Camera from recording the video."
logcat shows:
07-11 11:27:44.083 545 560 I PRLog : 8508224[44d035f0]: setBufferCount: count=9
07-11 11:27:44.083 545 560 I Gecko : setBufferCount: client owns some buffers
07-11 11:27:44.083 121 121 E SurfaceTextureClient: ISurfaceTexture::setBufferCount(9) returned Invalid argument
07-11 11:27:44.083 121 121 E QualcommCameraHardware: getBuffersAndStartPreview: Error while setting buffer count to 7
07-11 11:27:44.083 121 121 V QualcommCameraHardware: startPreview X
07-11 11:27:44.083 121 121 E QualcommCamera: Qint android::start_preview(camera_device*): X
07-11 11:27:44.093 545 560 I PRLog : 8508224[44d035f0]: mHardware->startRecording() failed with status -22
07-11 11:27:44.093 545 560 I PRLog : 8508224[44d035f0]: mRecorder->start() failed
Comment 13•12 years ago
|
||
Using unagi and Leo devices (Leo Comm RIL):
Gecko http://hg.mozilla.org/releases/mozilla-b2g18/rev/b64372810dd7
Gaia 680c72ccbd2d5045e590a6ba08de2aac6af71953
BuildID 20130710230201
Version 18.1
I don't see the issue in Comment 9 - Mike which build and device are you using?
Assignee | ||
Comment 14•12 years ago
|
||
(In reply to Marcia Knous [:marcia] from comment #13)
>
> I don't see the issue in Comment 9 - Mike which build and device are you
> using?
Marcia, I'm using the build in comment 6.
Assignee | ||
Comment 15•12 years ago
|
||
Marcia, I can reproduce the issue in comment 9 running:
- gecko: b2g18:777ab5f22878
- gaia: v1-train:7cdcc46179d198cab11970964b181ede32a5b683
What branch is your gaia from?
Assignee | ||
Comment 16•12 years ago
|
||
Well here's the problem: in camera.js::stopRecording(), we do the following comparison:
dump("mikeh: e.reason='" + e.reason + "'; e.path='" + e.path + "'; videofile='" + videofile + "'");
if (e.reason === 'modified' && e.path === videofile) {
...to determine whether or not to update the filmstrip in response to the DeviceStorage event. Except the dump statement above shows:
GeckoDump: mikeh: e.reason='modified'; e.path='/sdcard/DCIM/100MZLLA/VID_0012.3gp'; videofile='DCIM/100MZLLA/VID_0012.3gp'
So the |e.path === videofile| comparison fails.
This is _different_ from when the Camera app is run from the homescreen:
GeckoDump: mikeh: e.reason='modified'; e.path='/sdcard/DCIM/101MZLLA/VID_0025.3gp'; videofile='/sdcard/DCIM/101MZLLA/VID_0025.3gp'
In this case, the filenames match and the filmstrip is updated. The problem is the value of |this._videoRootDir|, which is different depending on from where the camera is launched.
In the lockscreen Camera:
GeckoDump: mikeh: this._videoRootDir=''
In the regular Camera app:
GeckoDump: mikeh: this._videoRootDir='/sdcard/'
The code to generate this._videoRootDir is:
req.onsuccess = (function fileCreated(e) {
// Extract video root directory string
var absolutePath = e.target.result;
var rootDirLength = absolutePath.length - dummyfilename.length;
this._videoRootDir = absolutePath.substring(0, rootDirLength);
dump("mikeh: this._videoRootDir='" + this._videoRootDir + "'");
dhylands, AddNamed() was recently changed significantly[1]; could it have caused this breakage?
1. https://hg.mozilla.org/releases/mozilla-b2g18/rev/b8a980062526
Flags: needinfo?(dhylands)
Comment 17•12 years ago
|
||
So, now that we support multiple storage areas, functions like AddNamed, Get, Enumerate, etc return fully qualified paths.
So, what I think this means is that we need to record the result from AddNamed into videofile rather than recording what we passed to AddNamed (or something along those lines)
Flags: needinfo?(dhylands)
Comment 18•12 years ago
|
||
(In reply to Alex Keybl [:akeybl] from comment #2)
> ckreinbring, can you find the first build in which this regressed? We're
> assuming it was very recently, since this was found during smoketests.
the last working build when the user is able to take a video from the lock screen and the video is saved to the Gallery
Build 2013-05-13-07-02-06
Gecko http://hg.mozilla.org/releases/mozilla-b2g18/rev/eda25a4c8d2f
Gaia 991bb2d9a64df2e532ad92677248aec30076ee8b
there is a gap, when attempting to take a video results in the OS crash (Crash ID: bp-58460c10-72ba-48dc-bc4c-bae122130711)
builds range:
2013-05-13-23-02-07 - first crashing
2013-05-16-23-02-07 - last crashing
the first build when it's not crashing and not saved to the Gallery
Build 2013-05-17-07-02-06
Gecko http://hg.mozilla.org/releases/mozilla-b2g18/rev/b87559cef261
Gaia 8d721227107f8f6945f795aab9764a56d2d1c0c7
*test device: Unagi
Keywords: regressionwindow-wanted
Assignee | ||
Comment 19•12 years ago
|
||
(In reply to Dave Hylands [:dhylands] from comment #17)
>
> So, now that we support multiple storage areas, functions like AddNamed,
> Get, Enumerate, etc return fully qualified paths.
>
> So, what I think this means is that we need to record the result from
> AddNamed into videofile rather than recording what we passed to AddNamed (or
> something along those lines)
Except whether or not AddNamed() returns a fully-qualified pathname seems to depend on whether or not it's called from outside the b2g parent process. The lockscreen (and hence the lockscreen camera, when there's a passcode set) runs in the parent.
Comment 20•12 years ago
|
||
v1 train - note I am testing with Leo device which is what we use for the daily smoketests.
(In reply to Mike Habicher [:mikeh] from comment #15)
> Marcia, I can reproduce the issue in comment 9 running:
> - gecko: b2g18:777ab5f22878
> - gaia: v1-train:7cdcc46179d198cab11970964b181ede32a5b683
>
> What branch is your gaia from?
Assignee | ||
Comment 21•12 years ago
|
||
More info: in both the lockscreen and regular case, the camera passes a relative pathname (e.g. dummyfilename='DCIM/100MZLLA/.VID_0014.3gp') to .addNamed(). The .onsuccess handler in the lockscreen case gets:
absolutePath='DCIM/100MZLLA/.VID_0014.3gp'
In the regular case:
absolutePath='/sdcard/DCIM/101MZLLA/.VID_0027.3gp'
Updated•12 years ago
|
Assignee: hkoka → mhabicher
Assignee | ||
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 22•12 years ago
|
||
Verified,fixed on LEO 1.1 Mozilla RIL
Environmental Variables
Build ID: 20130722070207
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/68fb0a2e0114
Gaia: 41d10fb10be6916e6554eb440d9a97130ef23ce0
Platform Version: 18.1
Issue does not reproduce the created video is saved to the gallery, with a thumbnail showing briefly at the top of the screen allowing the user to preview the video immediately.
Status: RESOLVED → VERIFIED
Updated•12 years ago
|
status-b2g18:
--- → fixed
Comment 24•11 years ago
|
||
Verified fixed, the issue no longer reproduces on Leo Moz Ril.
Environmental Variables
Build ID: 20130814041202
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/15813d776a69
Gaia: dd3959fa74e356a528daa76ffee14c2c728a4b56
Platform Version: 18.1
Issue does not reproduce the created video is saved to the gallery, with a thumbnail showing briefly at the top of the screen allowing the user to preview the video immediately.
You need to log in
before you can comment on or make changes to this bug.
Description
•