[Camera] The picture preview can no longer rotate after accessing the power button menu (long press) and returning to preview mode



Firefox OS
Gaia::System::Window Mgmt
3 years ago
15 days ago


(Reporter: Joshua Mitchell (Inactive), Unassigned)


Gonk (Firefox OS)

Firefox Tracking Flags

(b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected, b2g-master affected)


(Whiteboard: [3.0-Daily-Testing])


(1 attachment)



3 years ago
Created attachment 8583188 [details]

If you access the power button menu while on a picture preview, you will no longer be able to rotate the picture. This also reproduces with video preview taken from the camera app.

Repro Steps:
1) Update a Flame to 20150325010206
2) Launch Camera
3) Take a picture
4) Tap on the preview
5) Rotate the picture
6) Long press the power button
7) Select Cancel
8) Attempt to rotate the picture

The picture can no longer be rotated

The picture can still be rotated

Environmental Variables:
Device: Flame Master
Build ID: 20150325010206
Gaia: aebfbd998041e960cea0468533c0b5041b504850
Gecko: cc0950b7a369
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 39.0a1 (Master)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Repro frequency: 10/10
See attached: logcat

Comment 1

3 years ago
This issue also occurs on Flame KK 2.2, 2.1, and 2.0

Device: Flame 2.2 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150325002503
Gaia: aeee2a54caa8ffb875b96264b61d742b70689f22
Gecko: 556aca3e50ac
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Device: Flame 2.1 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150325001202
Gaia: b8ae0df34362420fe4a9c90effa5247a1f5c844d
Gecko: 2a05cd42088b
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 34.0 (2.1)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.0 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150325000205
Gaia: 896803174633fc6acd3fd105f81c349b8e9b9633
Gecko: 543c2325d667
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 32.0 (2.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Moving to windows Management.  NI on component owner to take a look.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Component: Gaia::Camera → Gaia::System::Window Mgmt
Flags: needinfo?(pbylenga) → needinfo?(hcheng)
Is this issue a regression bug?
Flags: needinfo?(hcheng)
Not a regression, the "no longer" is referring to a change in current functionality (from one moment to the next) rather than historical functionality through development.
Flags: needinfo?(hcheng)
Alive, could you take a look?
Flags: needinfo?(hcheng) → needinfo?(alive)
I think the reason is that when device menu is triggered but then cancelled, it would trigger "sleepmenuhide" event [1] which would finally results in lockOrientation() [4] of app window.

Then, the "orientationchange" event cannot be published anymore.

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/sleep_menu.js#L222
[2] https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/orientation_manager.js#L58
[3] https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/app_window_manager.js#L549
[4] https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/app_window.js#L1642
Etienne, could you help clarify if this behavior is as designed or not?
Flags: needinfo?(alive) → needinfo?(etienne)
(In reply to Hermes Cheng[:hermescheng] from comment #7)
> Etienne, could you help clarify if this behavior is as designed or not?

I don't think it's by design.
The camera declares a default orientation in the manifest, then at runtime unlocks the orientation (which is perfectly fine).

But when we come back to the camera app from the menu the system app just sees the manifest request and locks it up again. I don't know if the system app gets an event when the "runtime unlock" happens (ni Alive) that would enable us to track this state.
If we don't then we'll need to ask the camera app to listen for visibilitychanges and unlock again, which is a bit sad since it'll only fix this bug.
Flags: needinfo?(etienne) → needinfo?(alive)
There is no unlock event (which we want to have in bug 1043102). I am afraid system app has nothing to do for this issue right now as Etienne said.
Flags: needinfo?(alive)

Comment 10

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