Closed Bug 984730 Opened 7 years ago Closed 7 years ago

Camcorder starts with flash light by default


(Firefox OS Graveyard :: Gaia::Camera, defect)

Gonk (Firefox OS)
Not set


(blocking-b2g:1.4+, b2g-v1.4 verified, b2g-v2.0 verified)

1.4 S5 (11apr)
blocking-b2g 1.4+
Tracking Status
b2g-v1.4 --- verified
b2g-v2.0 --- verified


(Reporter: bhargavg1, Assigned: dmarcos)




(Whiteboard: [caf priority: p2][CR 634446] [landed-on-master])


(1 file)

when ever camcorder is started for the first time on the v1.4 for KK, see that it starts with the "SetFlashMode" as "torch" and enables flash light till user disables that.

can we make the default value as "none" instead of torch
blocking-b2g: --- → 1.4?
Whiteboard: [CR 621219]
Blocks: gonk-kk
Whiteboard: [CR 621219] → [CR 634446]

Please review.
Flags: needinfo?(hkoka)
blocking-b2g: 1.4? → 1.4+

If this is quick, please take care of it. If not, we will need to have Joe get help from those working on kit-kat in Taipei.

Flags: needinfo?(hkoka) → needinfo?(mhabicher)
I've confirmed that (on the Nexus 4, at least) the flash defaults to 'off'. When we bring the camera up in picture mode, the Camera app sets the flash mode to 'auto', and when we switch to video mode, it sets the flash mode to 'torch'.

Swapping the order of the flashModesVideo items in app.js doesn't seem to affect whether or not the flash is on, so whatever it setting this is doing it intentionally.
Flags: needinfo?(mhabicher)
Over to Gaia.
Flags: needinfo?(dmarcos)
Blocks: 983405
jcheng - anyone available to pick this up from folks working on kitkat/camera...
Flags: needinfo?(jcheng)
Flags: needinfo?(dmarcos)
I don't think this is KK specific. In the branch I can see that the default value for flash is on but it should be auto. This is why video recording starts in torch mode. Investigating the reason.
Assignee: nobody → dmarcos
Flags: needinfo?(jcheng)
Severity: normal → blocker
diego, please update with your investigation

Flags: needinfo?(dmarcos)
Still need investigation
Flags: needinfo?(dmarcos)
ETA 03/21/2014
Attachment #8394512 - Flags: review?(jdarcangelo)
Should we create a flag default for the options in the configuration file? Now the default value is the last option of the list.
Diego: See comments on PR. I'm pretty sure we have the ability to specify the default in the config/app.js file using the `selected` key. Can you try setting that to see if that works instead of re-ordering?
Flags: needinfo?(dmarcos)
Review the patch again :)
Flags: needinfo?(jdarcangelo)
Attachment #8394512 - Flags: review?(jdarcangelo) → review+
Flags: needinfo?(jdarcangelo)
Flags: needinfo?(dmarcos)
Whiteboard: [CR 634446] → [CR 634446] [branch-camera-new-features in-code-review]
Whiteboard: [CR 634446] [branch-camera-new-features in-code-review] → [CR 634446] [branch-camera-new-features reviewed-ready-to-land]
Hema: this is a one line patch. Can we please land it in 1.4 as well. This is marked as a blocker by test teams.
Flags: needinfo?(hkoka)
Landed in camera-new-features:
Flags: needinfo?(hkoka)
Diego -- can you please land it on gaia/v1.4 as well?
QA Whiteboard: [branch-camera-new-features fixed]
Closed: 7 years ago
Resolution: --- → FIXED
This isn't landed on 1.4 in the mainline branch yet.
Resolution: FIXED → ---
Please keep this closed. It's going to be landed in 1.4 when we merge camerea-new-features after fixing all the blockers. Partner requirement.
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
No longer blocks: gonk-kk
(In reply to Diego Marcos [:dmarcos] from comment #18)
> Please keep this closed. It's going to be landed in 1.4 when we merge
> camerea-new-features after fixing all the blockers. Partner requirement.

A landing process has nothing to do with a partner requirement - this is about being able to track what's currently present in the mainline branches. The camera-new-features branch isn't considered a mainline branch, so bugs fixed there aren't considered resolved in a mainline branch. What's even worse here is deciding to close this early will cause confusion to others filing bugs, as they'll see the bug closed, even though the bug is still present in the mainline branch. This can also screw up tree managers, as they could potentially think the patch is landed on trunk, when in reality it's not.

Feel free to use the whiteboards to track landings in the custom branch. However, if the problem is present in the mainline Gaia branches, then an issue isn't considered resolved if it doesn't land there.
Resolution: FIXED → ---
QA Whiteboard: [branch-camera-new-features fixed]
Whiteboard: [CR 634446] [branch-camera-new-features reviewed-ready-to-land] → [CR 634446] [branch-camera-new-features fixed]
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Whiteboard: [CR 634446] [branch-camera-new-features fixed] → [CR 634446] [landed-on-master]
sorry, reopening it until we land on 1.4
Resolution: FIXED → ---
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Bulk edit for camera bugs.

If earlier comments do not show how this bug landed to master, it probably landed as part of which merged the camera-new-features branch into master.

This bug was uplifted from master to v1.4 as part of
Target Milestone: --- → 1.4 S5 (11apr)
The bug is fixed on 1.4 and master build
The camcorder flash is off by default

1.4 Environmental Variables:
Device: Leo 1.4 MOZ
BuildID: 20140411000202
Gaia: 6c50349f41d40ba175ea0fc0c2c2cbd739ba7170
Gecko: 28b419f0e857
Version: 30.0a2
Firmware Version: v10d

1.5 Environmental Variables:
Device: Leo 1.5 MOZ
BuildID: 20140407040202
Gaia: f1a98bfaa3ab2480945bd7018831fd56c61cdc24
Gecko: 5405d6f4e3c6
Version: 31.0a1
Firmware Version: v10d
Whiteboard: [CR 634446] [landed-on-master] → [caf priority: p2][CR 634446] [landed-on-master]
Flags: in-moztrap?(ychung)
Found Test Case:

STR needs to added to verify this bug to the existing test case.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Test case updated to check that flash is off by default for video and set to auto by default for camera:
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(ychung)
Flags: in-moztrap+
You need to log in before you can comment on or make changes to this bug.