Created attachment 8348477 [details] landscape mode Environments: -------------------------------- Hamachi V1.2 Gaia fcf1c2fe020c29da4755621cbffdc1a333a43be9 Gecko http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/129ad3c335a5 BuildID 20131215004003 Version 26.0 Hamachi V1.3 Gaia 4f20d03b82a723d82c0450f6fe3f17a3717f0ab6 Gecko http://hg.mozilla.org/mozilla-central/rev/f67feb33a974 BuildID 20131216040201 Version 29.0a1 Steps to reproduce: -------------------------- 1. Open camera app 2. Change the orientation of device (portrait to landscape) 3. Take a picture/video. 4. Tap on the thumbnail on the left to preview the picture/video 5. Click on "Delete" or "Share" Actual results: -------------------------- The deleting/sharing page is still in portrait orientation. Expected results: --------------------------- The deleting/sharing page is changed to landscape orientation.
Not a regression from previous release. Delete/Share dialog is not honoring orientation -- dmarcos/mikeh, can you please comment on whats going on (moving this into 1.4?)
blocking-b2g: 1.3? → 1.4?
I'm guessing the Delete/Share dialog is getting bound by the orientation-lock of the Camera app. I wonder if there's a way to force them to appear with a different, app-specified orientation. It looks like this is a MozActivity--fabrice, any idea what's going on here?
Flags: needinfo?(mhabicher) → needinfo?(fabrice)
activities don't specify anything about orientation. I'm cc-ing Alive that would know best if it's some issue with the window management code.
Flags: needinfo?(fabrice) → needinfo?(alive)
As Fabrice said, there's no way to specify orientation of activity now. Current strategy: Lock the "app's" orientation which the activity belongs to. If no orientation specified for the app, locked with the caller of activity. BTW, the delete dialog seems to be part of the camera app, but not an activity. And the fact is, camera app is locked at portrait mode but rotate the button when it detects 'orientationchange' event. So this is bug of camera not window mgmt. I have no idea how camera would fix this though.
David: Is there a specific reason why the Camera app has its orientation locked to portrait?
This looks like the same issue as Bug #951329 as well.
Mike, Fabrice, and Alive: this isn't related to activities. Camera is locked to portrait mode, so alert() dialogs display that way. Justin: the decision to lock the camera in portrait mode predates my involvement with it. But I think allowing the screen to rotate would be the wrong thing in many ways. When you got a resize event you'd have to rotate the preview stream, for example, because you don't actually want that part to rotate. The solution here is to modify the photo deletion code so that it uses a custom dialog. If we have to rotate the new settings menu, we can use the same technique to rotate this delete dialog. I wonder if the building block dialogs would work, or if all of the styles will have to be manually copied.
Justin: if you can fix (or mock up a fix) for this, you can prove to wilson that he can rotate the settings menu :-)
Assignee: nobody → jdarcangelo
blocking-b2g: 1.4? → ---
After some thought and discussion with the Camera team, I'm not sure we can easily unlock the orientation in the Camera app since most on-screen controls must remain in their locked position (relative to portrait orientation). Because the orientation is locked to portrait, the system dialogs will always appear in the portrait orientation. Would it make sense to have system dialogs always honor the orientation of the device regardless of if the app has locked it? Or maybe have a way to specify the orientation behavior of system dialogs?
Well, dialogs should always be displayed in the orientation that makes more sense for the user looking at them ideally. So dialogs could have a different orientation than the apps that trigger them, but I'm not sure if we can do that in a smooth way.
(In reply to Justin D'Arcangelo from comment #11) > After some thought and discussion with the Camera team, I'm not sure we can > easily unlock the orientation in the Camera app since most on-screen > controls must remain in their locked position (relative to portrait > orientation). Because the orientation is locked to portrait, the system > dialogs will always appear in the portrait orientation. Would it make sense > to have system dialogs always honor the orientation of the device regardless > of if the app has locked it? Or maybe have a way to specify the orientation > behavior of system dialogs? No way AFAIK. I am not sure if we should implement the same thing as camera in system: detect device orientation anytime to rotate to modal dialog. This seems weird to me and it might have power consumption concern.
Assignee: jdarcangelo → nobody
Diego - Are you working on this one?
yes(In reply to Hema Koka [:hema] from comment #14) > Diego - Are you working on this one? Yes
Connecting this bug to this one, which is nominated to block Madai (so this one could end up blocking a blocker) and is a possible dupe: https://bugzilla.mozilla.org/show_bug.cgi?id=988505
resetting to nobody
Assignee: dmarcos → nobody
I know Diego was working on this and was able to make some progress by unlocking the orientation lock directly before the dialog was opened. This was a first step, but lead to issues: - We had no way of knowing when the dialog was closed, meaning we could not restore the orientation lock. - Potentially unlocking the orientation lock, opening a dialog, rotating the device to landscape and closing, would result in the camera UI being lock in landscape instead of portrait. If a solution to this is found at the camera app level, it will likely be a massive hack, and could introduce orientation bugs to other Gaia apps. AFAIK orientation lock is a global setting. This problem exists because we are trying to build a fully functional gallery inside a locked orientation camera app. I'm still advocating that we move to the gallery app being the sole place to view media. We're currently building a less capable mini-gallery app inside camera, creating twice much work for ourselves and confusing users. Why do we have a preview gallery inside camera? 1. People want to review their pictures/videos quickly. Gallery app launch time is (sometimes) too slow 2. Security risk of displaying images when launched from lockscreen 3. Potentially others I'm not aware of. Solutions: 1a. Launch gallery app in background when camera launches and pre-scan for media. 1b. Allow gallery to accept a list of blobs/filepaths to display via MozActivity to negate the need for slow scanning. 1c. Scan media from newest to oldest to show latest media first (not sure how possible this is). 2. Allow spawning app (Camera) to pass a subset of media to be displayed a MozActivity parameter so that Gallery doesn't show private content. IMO if we go to far down this in camera preview-gallery clone route, we're making life difficult for ourselves and slowing down the progression of the gallery experience. The Android gallery is quickly accessible from the camera and is fully functional. We're providing a second gallery that contains a sub-set of features. This bug is just one of the symptoms that will surface as a result of trying to embed a gallery app in a camera app. I'm willing to be proven wrong on this, but currently it feels like we're heading in the wrong direction.
The patch attached to bug 987569 also fixes this bug.
Assignee: nobody → dflanagan
This is fixed by the patch that just landed in bug 987569.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
status-b2g-v1.4: --- → fixed
status-b2g-v2.0: --- → fixed
Target Milestone: --- → 1.4 S6 (25apr)
You need to log in before you can comment on or make changes to this bug.