951014 - The orientation of deleting/sharing page is still the same after rotating the device

Status: RESOLVED FIXED

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

Description

[Bingqing Li]

Attachment: 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.

Comment 1

[Bingqing Li]

Attachment: deleting-page-portrait-orientation

Comment 2

[Hema Koka [:hema]]

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?)

Comment 3

[Mike Habicher [:mikeh] (high bugzilla latency)]

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?

Comment 4

[Mike Habicher [:mikeh] (high bugzilla latency)]

Ref. https://github.com/mozilla-b2g/gaia/blob/master/apps/camera/js/filmstrip.js#L291

Comment 5

[[:fabrice] Fabrice Desré]

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.

Comment 6

[(inactive after 6/18) Alive Kuo [: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.

Comment 7

[Justin D'Arcangelo [:justindarc]]

David: Is there a specific reason why the Camera app has its orientation locked to portrait?

Comment 8

[Justin D'Arcangelo [:justindarc]]

This looks like the same issue as Bug #951329 as well.

Comment 9

[David Flanagan [:djf]]

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.

Comment 10

[David Flanagan [:djf]]

Justin: if you can fix (or mock up a fix) for this, you can prove to wilson that he can rotate the settings menu :-)

Comment 11

[Justin D'Arcangelo [:justindarc]]

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?

Comment 12

[[:fabrice] Fabrice Desré]

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.

Comment 13

[(inactive after 6/18) Alive Kuo [:alive]]

(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.

Comment 14

[Hema Koka [:hema]]

Diego - Are you working on this one?

Comment 15

[Diego Marcos [:dmarcos]]

yes(In reply to Hema Koka [:hema] from comment #14)
> Diego - Are you working on this one?

Yes

Comment 16

[Stephany Wilkes]

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

Comment 18

[Hema Koka [:hema]]

resetting to nobody

Comment 19

[Wilson Page [:wilsonpage]]

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.

Comment 20

[David Flanagan [:djf]]

The patch attached to bug 987569 also fixes this bug.

Comment 21

[David Flanagan [:djf]]

This is fixed by the patch that just landed in bug 987569.