Rob MacDonald [:robmac] Reporter
	Description • 10 years ago

Since the camera is locked to portrait, edge gestures including app 2 app edge swipe and notifications tray are being triggered from the wrong edges.

Steps to reproduct
Hold camera in landscape
Swipe from one of the edges.

Behaviour
left edge opens notifications tray
bottom edge activates left edge swipe gesture
top edge activates right edge swipe gesture

Intended Behaviour:
top edge opens notifications tray
left edge swipes back
right edge swipes forward (if applicable)

	Jason Smith [:jsmith]
	Comment 1 • 10 years ago

Needs a video.

	Wilson Page [:wilsonpage]
	Comment 2 • 10 years ago

I think this is expected behaviour if an app chooses to lock orientation? Unless the app could somehow just locks it's own window, leaving the system chrome to continue to react to orientation changes.

	Diego Marcos [:dmarcos]
	Comment 3 • 10 years ago

I agree with Wilson, the edge gestures and the orientation of an application should be decoupled.

	Cody Roesch [:croesch]
	Comment 4 • 10 years ago

Here is the video for the reporters bug.
http://youtu.be/sucup_zOXqE

Environmental Variables
Device:  OpenC 2.0
Build ID: 20140618000202
Gecko: https://hg.mozilla.org/releases/mozilla-aurora/rev/55679dc2e72b
Gaia: 83844c7679b3b9f6e7f1116c1eeec2d1e7a64eec
Platform Version: 32.0a2
Firmware Version: P821A10v1.0.0B06_LOG_DL

	Tiffanie Shakespeare [:tif]
	Comment 5 • 10 years ago

confirm what Diego says - when it was just the notification bar it wasn't as big of a deal. But now we have the multi-tasking edge swipe gesture. Unlike with a game, I don't think users would realize that we locked the orientation, esp with the icons rotating, and would try to swipe down from the top. We also don't want to train the user to always swipe left/right to access it and then it appears to not work when in camera landscape mode.

	Joshua Mitchell (Inactive)
	Comment 6 • 10 years ago

QA-Wanted for device/branch checks

	Diego Marcos [:dmarcos]
	Comment 7 • 10 years ago

Tiffanie good point! I haven't thought about the games implication. An app should be able to lock the orientation without affecting edge gestures.

	Diego Marcos [:dmarcos]
	Comment 8 • 10 years ago

We should determine if this is a camera or a system front end issue.

	Hema Koka [:hema]
	Comment 9 • 10 years ago

(In reply to Diego Marcos [:dmarcos] from comment #7)
> Tiffanie good point! I haven't thought about the games implication. An app
> should be able to lock the orientation without affecting edge gestures.

Agree.

NI Etienne who worked on the edge gestures and Tim for input

	Cody Roesch [:croesch]
	Comment 10 • 10 years ago

This bug DOES repro on: Flame 2.1 Master, Flame 2.0, Flame 1.4, Buri 2.1 Master, Buri 2.0, Buri 1.4, Buri 1.3, OpenC 2.1 Master, OpenC 2.0, OpenC 1.4, OpenC 1.3

Actual Results: When the camera is in landscape mode, edge gesture from the left reveals the notification window. Edge gesture from top and bottom swap apps.

***NOTE: Flame v121-2 Base, Buri v1.3 and OpenC 1.3 does not show the notification window when swiping from the left inside the camera app. However top and bottom app swiping edge gestures are still occuring.

Environmental Variables:
Device: Flame 2.1 - Master
Build ID: 20140619040201
Gaia: 82e957160ca017087bd374cd051339e55b641e68
Gecko: f78e532e8a10
Version: 33.0a1 (2.1 - Master)
Firmware Version: v121-2
------------------------------------------
Environmental Variables:
Device: Flame 2.0
Build ID: 20140619000200
Gaia: 23e06c3624309db22ad9cb736d89700768b42b36
Gecko: 164b61458ca5
Version: 32.0a2 (2.0)
Firmware Version: v121-2
------------------------------------------
Environmental Variables:
Device: Flame 1.4
Build ID: 20140619000201
Gaia: 233da2865de3a2c73329e04c6deb21766f0d09d4
Gecko: 7978e6b470f2
Version: 30.0 (1.4)
Firmware Version: v121-2
-------------------------------------------
Environmental Variables:
Device: Buri 2.1 - Master
Build ID: 20140619074016
Gaia: 135a13ea0ee333314b6a12cb19f18617308a3b46
Gecko: ad11457bae17
Version: 33.0a1 (2.1 - Master)
Firmware Version: v1.2device.cfg
-------------------------------------------
Environmental Variables:
Device: Buri 2.0
Build ID: 20140619045135
Gaia: 00bdc43e4512da9409575593a0dcaafee0ee74f4
Gecko: 3c0a12d5b344
Version: 32.0a2 (2.0)
Firmware Version: v1.2device.cfg
------------------------------------------
Environmental Variables:
Device: Buri 1.4
Build ID: 20140619071113
Gaia: dff52e807187955300bdfcc880692d2875e37b40
Gecko: 43fa8371af32
Version: 30.0 (1.4)
Firmware Version: v1.2device.cfg
-------------------------------------------
Environmental Variables:
Device: Buri 1.3
Build ID: 20140619045734
Gaia: 5f4211ac94cc158a07269d0a0beca3c7937d78cc
Gecko: ace309b4ec92
Version: 28.0 (1.3)
Firmware Version: v1.2device.cfg
-------------------------------------------
Environmental Variables:
Device: Open_C 2.1 - Master
Build ID: 20140619040201
Gaia: 82e957160ca017087bd374cd051339e55b641e68
Gecko: f78e532e8a10
Version: 33.0a1 (2.1 - Master)
Firmware Version: P821A10V1.0.0B06_LOG_DL
--------------------------------------------
Environmental Variables:
Device: Open_C 2.0
Build ID: 20140619000200
Gaia: 23e06c3624309db22ad9cb736d89700768b42b36
Gecko: 164b61458ca5
Version: 32.0a2 (2.0)
Firmware Version: P821A10V1.0.0B06_LOG_DL
--------------------------------------------
Environmental Variables:
Device: Open_C 1.4
Build ID: 20140619000201
Gaia: 233da2865de3a2c73329e04c6deb21766f0d09d4
Gecko: 7978e6b470f2
Version: 30.0 (1.4)
Firmware Version: P821A10V1.0.0B06_LOG_DL
--------------------------------------------
Environmental Variables:
Device: Open_C 1.3
Build ID: 20140505052400
Gaia: Unknown Git commit; build date shown here.
Gecko: Unknown
Version: 28.0 (1.3)
Firmware Version: P821A10V1.0.0B06_LOG_DL

	Etienne Segonzac (:etienne)
	Comment 11 • 10 years ago

(In reply to Wilson Page [:wilsonpage] from comment #2)
> I think this is expected behaviour if an app chooses to lock orientation?
> Unless the app could somehow just locks it's own window, leaving the system
> chrome to continue to react to orientation changes.

We can't and won't be able to do this for 2.0 (locking the orientation only of an app window), Alive will know better but I think this will require platform work.

And it's pretty much the only way to fix the issue here :/

Currently locking the orientation means locking the orientation of the system.
So this bug boils down to "locking the orientation of an app should not lock the orientation of the whole system", which is a feature request.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 12 • 10 years ago

(In reply to Etienne Segonzac (:etienne) from comment #11)
> (In reply to Wilson Page [:wilsonpage] from comment #2)
> > I think this is expected behaviour if an app chooses to lock orientation?
> > Unless the app could somehow just locks it's own window, leaving the system
> > chrome to continue to react to orientation changes.
> 
> We can't and won't be able to do this for 2.0 (locking the orientation only
> of an app window), Alive will know better but I think this will require
> platform work.
> 
> And it's pretty much the only way to fix the issue here :/
> 
> Currently locking the orientation means locking the orientation of the
> system.
> So this bug boils down to "locking the orientation of an app should not lock
> the orientation of the whole system", which is a feature request.

Not reading the full bug,
but I and Jonas had discussed about a new API to control the screen orientation by each mozbrowser iframe.

But, apparently, it's NOT in v2.0 scope.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 13 • 10 years ago

(In reply to Rob MacDonald [:robmac] from comment #0)
> Since the camera is locked to portrait, edge gestures including app 2 app
> edge swipe and notifications tray are being triggered from the wrong edges.
> 
> Steps to reproduct
> Hold camera in landscape
> Swipe from one of the edges.
> 
> Behaviour
> left edge opens notifications tray
> bottom edge activates left edge swipe gesture
> top edge activates right edge swipe gesture
> 
> Intended Behaviour:
> top edge opens notifications tray
> left edge swipes back
> right edge swipes forward (if applicable)

This is a special case because camera app is asking system app to lock in portrait mode,
but itself listens to the deviceorientation event to change its UI by current rotation degree.

I don't think we have something to do with this case, even we have the new mozbrowser API for orientation.

	Jason Smith [:jsmith]
	Comment 14 • 10 years ago

Jamie - This looks like a pretty bad bug in edge gestures, but development above is indicating that this is non-trivial to fix. On that regard, we need to make a judgment call here if:

1. We can live with this bug
2. We can't live with this, in which then we might need to punt edge gestures out of 2.0
3. Some other option I'm thinking of

Can you make a product call on this?

	Diego Marcos [:dmarcos]
	Comment 15 • 10 years ago

This is a fundamental issue that affects any app that wants to lock the orientation: camera, video games... I would disable edge gestures by default until we fix it.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 16 • 10 years ago

(In reply to Diego Marcos [:dmarcos] from comment #15)
> This is a fundamental issue that affects any app that wants to lock the
> orientation: camera, video games... I would disable edge gestures by default
> until we fix it.

I have to say this is nothing to do with lockOrientation API but deviceorientation.
As I mentioned camera is explicitly telling it's portrait-primary but it is monitoring device orientation to change its UI by the rotation degree.

The best bet is to invent a new API "mozLockOrientationButDonReallyLockBecauseIWillChangeMyUIByMyOwn()" to tell system to block in portrait but do the same deviceorientation observer as the app does.

I will say this is a camera app only issue but not video or games.

	Diego Marcos [:dmarcos]
	Comment 17 • 10 years ago

In the current scenario, How does a game lock orientation without affecting the behavior of edge gestures? My understanding is that a game will have to call screen.mozLockOrientation. Then, the gestures to switch to the previous/next app will stay attached to the same edges regardless of the physical orientation of the device. Edge gestures and mozLockOrientation are currently coupled. For 2.0, Either we decouple them (by introducing an new API) or we disable edge gestures. Am I missing anything?

	Diego Marcos [:dmarcos]
	Comment 18 • 10 years ago

The proper solution would be that mozLockOrientation only locks the app's container/window without affecting the rest of the system

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 19 • 10 years ago

(In reply to Diego Marcos [:dmarcos] from comment #17)
> In the current scenario, How does a game lock orientation without affecting
> the behavior of edge gestures? My understanding is that a game will have to
> call screen.mozLockOrientation. Then, the gestures to switch to the
> previous/next app will stay attached to the same edges regardless of the
> physical orientation of the device. Edge gestures and mozLockOrientation are
> currently coupled. For 2.0, Either we decouple them (by introducing an new
> API) or we disable edge gestures. Am I missing anything?

Regardless is Wrong. Please read UX spec from bug https://bugzilla.mozilla.org/show_bug.cgi?id=992084.
The edge is different for a landscape app from a portrait app.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 20 • 10 years ago

(In reply to Diego Marcos [:dmarcos] from comment #18)
> The proper solution would be that mozLockOrientation only locks the app's
> container/window without affecting the rest of the system

1. This is conflicting with what UX wanted.
2. Use mozLockOrientation will change camera app's behavior - it cannot have an auto-rotating capture button anymore.

	Etienne Segonzac (:etienne)
	Comment 21 • 10 years ago

(In reply to Diego Marcos [:dmarcos] from comment #17)
> Edge gestures and mozLockOrientation are
> currently coupled. For 2.0, Either we decouple them (by introducing an new
> API) or we disable edge gestures. Am I missing anything?

The issue is not with apps locking the orientation like games, this works exactly like it was spec'ed.
No issue with apps supporting multiple orientations either (like the browser, the gallery...).

The issue comes from an app locking itself in portrait and then faking orientation changes by rotating it's own UI.
I guess if we had a nice orientation change transition this would be less needed?

	Wilson Page [:wilsonpage]
	Comment 22 • 10 years ago

(In reply to Etienne Segonzac (:etienne) from comment #21)
> I guess if we had a nice orientation change transition this would be less
> needed?

We lock orientation so that user can compose shots just like a normal digital camera. Orientation changes would be far too disruptive to this experience. Also it would require all sorts of complexity around making sure that the viewfinder remained in the correct place when landscape and portrait.

	Justin D'Arcangelo [:justindarc]
	Comment 23 • 10 years ago

(In reply to Diego Marcos [:dmarcos] from comment #18)
> The proper solution would be that mozLockOrientation only locks the app's
> container/window without affecting the rest of the system

+1.. agreed. If an app calls mozLockOrientation, it should not affect the system app's ability to properly respond to orientation changes. It should only affect the contents of the calling app's iframe.

	Jason Smith [:jsmith]
	Comment 24 • 10 years ago

Going to block for now because we either need to fix this or turn off edge gestures, since the currently behavior definitely isn't shippable.

	Justin D'Arcangelo [:justindarc]
	Comment 25 • 10 years ago

(In reply to Alive Kuo [:alive][NEEDINFO!][OOO until 6/30] from comment #16)
> I will say this is a camera app only issue but not video or games.

This certainly does also affect any games that lock the device orientation. I downloaded "Cut The Rope" and "Poppit!" from the Marketplace. Both games lock the device to landscape orientation. If, while running the game, you hold the device in portrait orientation, the game still appears rotated 90 degrees to the locked landscape orientation and the edge gestures need to be invoked from the top/bottom of the device's screen. This means that if a game locks the device orientation, the edge gestures are also locked.

The only thing the Camera app does differently than a game is that it manually rotates the app's UI elements accordingly. However, this needs to be done this way in order to reflect the UX spec for Camera. All on-screen UI must appear in a "fixed" location on the device's screen such that no matter which way you hold the device when shooting pictures, the UI elements are always located in the same location on the screen. The simplest fix for this issue would simply be for the app's orientation (locked or not) to not affect the edge gestures or the System app.

	Diego Marcos [:dmarcos]
	Comment 26 • 10 years ago

For the people that have spent time thinking about this. This is what I think this should work:

- The edge gestures should always respond to the physical orientation of the device regardless of the orientation of the app. The back edge gesture will be always on the left edge as I'm holding the phone so I can use my left thumb to go to the previous sheet.

- mozLockOrientation should not modify the behavior of edge gestures.

I attached a video while holding my phone in portrait mode and opening cut the rope that locks the orientation to landscape. It's very confusing to switch the edges for the gestures if it's not paired with a physical rotation of the device. I see no good reason to couple the edge gestures with the orientation lock of an app. I would always let the edge gestures rotate free with the device. When swiping apps if I see an app in landscape orientation I will naturally rotate the device to use it and then the orientation of the edge gestures will match my expectations.

	Rob MacDonald [:robmac] Reporter
	Comment 28 • 10 years ago

(In reply to Diego Marcos [:dmarcos] from comment #26)
> For the people that have spent time thinking about this. This is what I
> think this should work:

The edge gestures are based on the visible orientation of the app and not the physical orientation of the device. So the video in attachment 8444485 [details] is to spec. 

Just heard from Etienne via email and to summarize his comments, we have no issue with apps in portrait-primary + fullscreen. The problem is with apps in portrait-primary + fullscreen that are listening to device orientation events in order to fake a landscape view.

Based on this, do we feel this is an issue beyond camera? I haven't encountered any issues beyond camera including third party apps.

	Diego Marcos [:dmarcos]
	Comment 29 • 10 years ago

I know that the video I attached follows the spec. I claim that the spec is confusing for the user and we should change it.

The issue affects all applications that use mozLockOrientation. Changing the position of the edge gestures without a physical rotation of the device is confusing for the user. The edge gestures should be coupled with the orientation of the device regardless of what orientation the app is locked in. I want edge gestures to always be located in the same position with respect to my hands. The position where my fingers land on the screen depends on how I hold the phone not on the orientation that an app decides to be displayed in. Muscle memory is more efficient than eye-hand coordination.

For 2.0 I suggest:

Modyfing the UX spec to let the edge gestures rotate freely with the orientation of the device (regardless of mozLockOrientation)

	Justin D'Arcangelo [:justindarc]
	Comment 30 • 10 years ago

(In reply to Rob MacDonald [:robmac] from comment #28)
> Based on this, do we feel this is an issue beyond camera? I haven't
> encountered any issues beyond camera including third party apps.

Rob: If we remove the orientation lock from Camera, there might be jerky behavior with the on-screen UI elements when rotating the device (e.g.: buttons jumping around, etc.). Whereas currently, we have a nice, smooth transition between orientations when rotating the device while taking pictures that we know works. So, the question is.. Do we want to attempt to unlock Camera's orientation to try and gauge how bad the jerkiness is when changing orientations (and possibly try to file follow-up bugs to smooth out any possible platform/system issues that may arise). Or, do we simply separate app orientation from the system app orientation?

	Diego Marcos [:dmarcos]
	Comment 31 • 10 years ago

The more I think about this the more convinced I am that mozLockOrientation and edge gestures should be decoupled. It's a bad design decision having the behavior of an app leaking to the system. There's no way to keep consistency and control the experience. Think of an app that locks in portrait but the UI or content doesn't convey a clear orientation. For instance, an app that does audio visualizations like this one: 

https://www.youtube.com/watch?v=zvciEKEjuXI

How does the user know where the back gesture is located? Trial and error?

	Rob MacDonald [:robmac] Reporter
	Comment 32 • 10 years ago

Mapping edge gestures to the physical orientation of the device versus the visible UI is problematic as the visible UI and gestures work together. In cases where we have a status bar or URL bar, for example, the utility tray is accessed by pulling down on the status bar. If we were to map the gesture to the physical orientation as opposed to the visible UI, we'd be breaking that relationship and break the UI model.

Looking at third party apps with locked orientation so far they seem to be behaving according to the spec. I know with camera as we are doing something unique to get the desired behaviour, which is essentially keeping some UI elements, such as the shutter button, in place but allowing other UI, such as the flash icon, to rotate. 

For camera we don’t want to change this behaviour. However, when it comes to edge gestures, and the notification tray, the edge gestures should map to the visual UI. The user doesn’t know we are locking the orientation and while some UI stays in place to enhance usability, the UI that hints at orientation, i.e. the icons, do update giving the impression of an unlocked UI. This is why the edge gestures need to be left/right for camera no matter the orientation.

I know this is not an easy issue to solve so I can live with not having it block the 2.0 release assuming the review of third party apps pans out. However it is an issue that needs to be investigated for 2.1 and I believe Etienne and Alive have some ideas for doing this.

	Diego Marcos [:dmarcos]
	Comment 33 • 10 years ago

Why cannot the utility tray be always attached to top edge of the screen? Why does it have to be attached to the status bar?

	Rob MacDonald [:robmac] Reporter
	Comment 34 • 10 years ago

(In reply to Diego Marcos [:dmarcos] from comment #33)
> Why cannot the utility tray be always attached to top edge of the screen?
> Why does it have to be attached to the status bar?

Hi Diego - The indicators in the status tray are related items in the tray. This includes the notifications indicator, airplane mode, connectivity and other settings. - Rob

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 35 • 10 years ago

(In reply to Hema Koka [:hema] from comment #9)
> (In reply to Diego Marcos [:dmarcos] from comment #7)
> > Tiffanie good point! I haven't thought about the games implication. An app
> > should be able to lock the orientation without affecting edge gestures.
> 
> Agree.
> 
> NI Etienne who worked on the edge gestures and Tim for input

I don't have anything more to contribute in the thread technically, nor on management (since edge gesture is a feature of systemsfe team).

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 36 • 10 years ago

(In reply to Rob MacDonald [:robmac] from comment #32)
> I know this is not an easy issue to solve so I can live with not having it
> block the 2.0 release assuming the review of third party apps pans out.
> However it is an issue that needs to be investigated for 2.1 and I believe
> Etienne and Alive have some ideas for doing this.

FWIW, I read the entire bug and I don't think there is a easy fix too so I think we should re-consider blocking decision here.

The problem is that the Gaia System has no knowledge of the visual orientation of Camera app UI, which is responsive to device motion sensors. Camera literally says to System "I don't want you to rotate me and I am just going to rotate my UI by myself, and I can't tell you the current orientation of my UI".

A possible fix is to ask Camera app to behave like any other apps, i.e. let it rotates by the system. However we already know that is not trivial for Camera app and the timing/flashing will be a bad regression for the Camera app. That does not fix the 3rd-party app either.

Another proposal thoroughly discussed here is to make edge swipe/utility orientate with the device motion. Rob already shut it down from the UX perspective, and from the past experiences I can also say that having device motion sensor active all the time will be a blocker for hardware vendor mainly due to power consumption concern.

That leave us with the new API proposal, allowing Camera app to lock the orientation but at the same time allow it to tell System it's current orientation, which is not doable for v2.0 -- or maybe it is if we want it so badly.

	Diego Marcos [:dmarcos]
	Comment 37 • 10 years ago

I think we can keep it simple. This is my proposal to decouple the app orientation from the edge gestures location:

0. Apps cannot lock edge gestures nor the status bar.
1. Edge gestures rotate freely with the physical orientation of the device. Previous and next sheet gestures will be always located in the left and right edges respectively. 
2. The status bar location also responds to the device orientation. The tray can always be pulled from the top edge. Apps can change the background color of the status bar or go full screen and hide it. The tray can still be pulled from the top edge even if the status bar is hidden. 

I'm surprised that power consumption is a concern in this case. Do we have any numbers?

	Etienne Segonzac (:etienne)
	Comment 38 • 10 years ago

(In reply to Justin D'Arcangelo [:justindarc] from comment #25)
> (In reply to Alive Kuo [:alive][NEEDINFO!][OOO until 6/30] from comment #16)
> > I will say this is a camera app only issue but not video or games.
> 
> This certainly does also affect any games that lock the device orientation.
> I downloaded "Cut The Rope" and "Poppit!" from the Marketplace. Both games
> lock the device to landscape orientation. If, while running the game, you
> hold the device in portrait orientation, the game still appears rotated 90
> degrees to the locked landscape orientation and the edge gestures need to be
> invoked from the top/bottom of the device's screen. This means that if a
> game locks the device orientation, the edge gestures are also locked.

This is exactly the expected behavior. Games lock the orientation in landscape and display their UI in landscape no issue here, when you're looking at the app the active edges are on your right and on your left.

	Justin D'Arcangelo [:justindarc]
	Comment 39 • 10 years ago

It sounds like what we really are looking for here is a 3rd option to locking the orientation that says "don't auto-rotate me, but pretend that you did".

This way, Camera (or other 3rd-party apps that may need to do similar things) can still continue to rotate its own UI (instead of relying on the system to do it), but things like edge gestures, top-drawer, etc. will automatically rotate to the correct sides of the screen.

	Diego Marcos [:dmarcos]
	Comment 40 • 10 years ago

I created bug 1029604 to track the API change.

	Rob MacDonald [:robmac] Reporter
	Comment 41 • 10 years ago

(In reply to Justin D'Arcangelo [:justindarc] from comment #39)
> It sounds like what we really are looking for here is a 3rd option to
> locking the orientation that says "don't auto-rotate me, but pretend that
> you did".
> 
> This way, Camera (or other 3rd-party apps that may need to do similar
> things) can still continue to rotate its own UI (instead of relying on the
> system to do it), but things like edge gestures, top-drawer, etc. will
> automatically rotate to the correct sides of the screen.

Agreed. 

And thanks for setting up that other bug, Diego.

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 42 • 10 years ago

(In reply to Diego Marcos [:dmarcos] from comment #37)
> I'm surprised that power consumption is a concern in this case. Do we have
> any numbers?

Found the bug number! It was introduced in bug 877903 comment 13 and removed in bug 898385.

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 43 • 10 years ago

^bug 898385. It mentioned 11% power increase.

	BMO Automation
	Comment 44 • 6 years ago

Firefox OS is not being worked on