orientation sensor "last vertical" seems to be remembered and applied

[kevin gunn]

latest rc-image

1. download and install machines vs machines
2. open machines vs machines
3. open browser, rotate to landscape
4. lay flat on table so that browser is still in landscape
5. switch back to machines vs machines with launcher
6. raise top of phone as to make the phone vertical in portrait, lay back down flat
7. switch to browser

expected: browser would be in landscape
actual: browser rotates

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Gerry Boland (gerboland)]

qtmir has very little to do with shell orientation, reassigning to unity8

[Michael Zanetti (mzanetti)]

This sounds like the expected behavior if you ask me...

The sensors have a threshold so they don't keep on flipping between portrait/landscape when the device is flat on the table. If you hold it in portrait and place it flat on the desk it will stay in portrait, if you hold it in landscape and then place it flat down, it'll stay in landscape. In unity8 we don't read actual sensor values ourselves, but we get a clear "Landscape" or "Portrait" from the lower layers (qtmir I think fills in the Screen.orientation value).

The above steps to reproduce do this:

* Put sensors in Portrait
* place it down flat (sensors stay in portrait as expected)
* focus a rotation-locked application which will cause unity8 to ignore the sensors.
* put the sensors in landscape
* place it down flat (sensors stay in landscape as expected)
* focus a rotation-enabled app, which will cause unity8 to regard the sensors, and thus rotate to landscape.

In order to get away with it, it seems a back-channel from unity8 down to QtMir and QtUbuntu would be needed in order to really turn off the sensor logic while a rotation-locked app is focused. I for one still think the way it currently works is quite expected tho. After all you did hold it up in portrait and instructed the sensors to rotate to portrait. Unity8 will execute that request as soon as possible.

[kevin gunn (kgunn72)]

i see what you're saying technically, altho i think it does feel a little jarring.
At the same time this feels like a relatively low occurance for a user due to the specifics required
and it sounds like a tangled web, kind of complicating the sensor policy.
So i would say due to those factors, we can make this lower priority, but would like design to weigh in here.

[Yuan-Chen Cheng (ycheng-twn)]

I do appreciate Dominik's step to reproduce it in the first place (in ubuntu-phone list). And as a user, I do hope this to be high priority instead of medium.

[Vesa Rautiainen (vesar)]

I agree with Kevin here. The outcome of the sequence in bug description is quite unpredictable from the user point of view. In the step 6 I could imagine user for example answering a phone call and keeping the phone in portrait orientation for a while. And then finally when switching to browser on a flat-down phone it suddenly orientates to portrait. And what is worse for the user is that the whole shell and therefore right edge switcher changes place making the whole system navigation more difficult.

But I also understand that technical complexity aspect here as well. If I could decide I guess I would ignore orientation switches when fixed-orientation app is focused and ask the orientation again when rotation-enabled app is focused. And if the sensors are between the threshold values "Don't change" status should be given instead of the last remembered orientation.

Does this all make sense?

[Vesa Rautiainen (vesar)]

There is a duplicate for this: https://bugs.launchpad.net/ubuntu-ux/+bug/1522281

[Vesa Rautiainen (vesar)]

Actually what I wrote on 2015-10-09 does NOT make sense. I wrote: "And then finally when switching to browser on a flat-down phone it suddenly orientates to portrait. And what is worse for the user is that the whole shell and therefore right edge switcher changes place making the whole system navigation more difficult."

What actually is true is that the Shell already is in portrait after the phone call and doesn't need to rotate to landscape since the landscape browser rotates to the same portrait orientation.

What is really important to notice when considering these use cases is that apps have their orientation (some of them can be only in landscape or in portrait) and shell has its orientation. AND that the Shell orientation and the focused app orientation need to be the same. This is mainly due to the bottom edge swipe feature that belongs to apps. In order to avoid any collision between the shell edge gestures and the application's bottom edge swipe the orientation need to be in sync.

What orientation UX spec states is:
1) Application orientation follows the device orientation as long as that orientation is supported by the application
2) Shell orientation follows always current application's orientation

Now considering this again I would say that the way it works currently is the correct way. As a user I would be more annoyed if the shell rotated unexpected than if the app changed its orientation. At least the system's main navigational edges would remain the same.

My conclusion would be to set this Invalid. Any other comments?

[Matthew Exon (ubuntubugs-mexon)]

I have a bunch of comments :-) I have constant problems with rotation on my phone and I really want them fixed. Exactly which changes need to be made I'm not sure, and I don't know if this bug in particular is valid or not. But it seems close enough that submitting a new bug doesn't seem right.

I find that mostly I hold the phone flattish, with it tilted up at the top-left or top-right corner depending on which hand I'm using. This is because it is low down at a comfortable holding level, and off to the side so it doesn't interfere with what I'm actually doing. So it's normally sitting right on the boundary between landscape and portrait. If the accelerometer is made very sensitive it'll constantly flip between them. But if the accelerometer is made relatively insensitive then getting the phone to display the correct orientation requires holding it at an unnatural angle. The rotation animation is also far too slow, and once it's decided to rotate the entire interface locks up until it's finished. So while the "how to reproduce" instructions might sound unlikely, that's just because they've been made extreme. In practice this happens to me all the time, just at much shallower angles.

Making things worse is that the lock screen doesn't rotate at all. So typically what happens to me is I turn on my phone, enter my PIN, move to press the button I want to press... but then everything starts flipping and the button I want zips away from under my finger. This even if I thought I was holding the phone in landscape mode while I unlocked it: I wasn't holding it at a steep enough angle. So I have to rotate the phone to an unnatural angle, wait for the phone to decide it's time to rotate, wait for the rotation animation to complete, then bring it back down and again find the button I want to press. As far as responsive UI design is concerned, it's pretty disastrous.

So my first thing is: a rotation animation doesn't make sense at all unless the phone is actually moving from one state to another. When the phone is switched on, make a decision whether it's in landscape or portrait and display the lock screen accordingly. If the app underneath the lock screen is in the wrong orientation, pre-rotate it, don't make me wait for a rotation animation that makes no sense in context. If the lock screen only supports portrait mode, then the app will have to be put in portrait mode - unless it's absolutely clear that I am really am unlocking the phone while holding it sideways, which doesn't sound likely.

I think fixing the lock screen so it rotates will probably help me a bit. But hopefully you can see that it won't solve the fundamental problem.

There's a second problem which might have already been filed in a separate bug, but is related. When I swipe to flip between apps it shows snapshots from whatever orientation they were in when they were last active. When I select one, that snapshot occupies the screen, and I go to press a button. But then the button slides away from me. Instead, if the phone has rotated, all suspended apps need to be brought back to life, repaint their screen in the background, be snapshotted, and then put back t...

[Matthew Exon (ubuntubugs-mexon)]

...and another thing. The rotation animation doesn't actually do its job. It's supposed to provide a smooth transition from one state to the next. But instead it takes a snapshot of state A, squishes it into the shape of state B, and then afterwards shuffles everything around to a good layout for the new screen. "Squished A" is a lie, showing me a bunch of buttons that don't really exist and I can't actually press. This is something that the iPhone also gets wrong.

My suggestion for fade out/fade in is exactly for this reason. That's an easy way to animate from an old state, that can no longer be used, to a new state that really can. This gives me a chance during the animation to predict where to put my finger - and move my finger away in time if it's about to press a button I don't want to press.

I can imagine two other options. One is to animate every UI element separately, with each button simultaneously rotating and floating over to its new position. That sounds like it could be a complete mess though. The other option is to continuously resize the window as it rotates, as if I were dragging the bottom right corner of the window on a desktop machine. That would probably lead to a sequence of "big bang" state changes that might be confusing, but it would give me a much better chance to predict the final location of the button I'm after.

[Matthew Exon (ubuntubugs-mexon)]

Here's another example: it also does it if you turn off the rotation lock.

* Open the browser
* Hold the phone long edge perpendicular to the table
* Wait until it switches to portrait mode
* Put phone flat on the table
* Turn on rotation lock
* Hold phone short edge perpendicular to the table for a few seconds
* Put phone flat on the table
* Turn off rotation lock
* Browser rotates

This just happened to me yesterday. I was happily reading some news in portrait mode when it occurred to me that the rotation lock was on and I normally keep it turned off. So I turned it off - and got an incomprehensible rotation.

Since it's locked in portrait mode, turning off the rotation lock happens while the UI is in portrait mode. At that time there's no accelerometer data to indicate that the phone is really in landscape. There is only historical accelerometer data indicating that once upon a time the phone was in landscape. But it rotates anyway. This is why I'm saying you should only ever rotate the phone to landscape if the accelerometer says it's in landscape right now.

[Matthew Exon (ubuntubugs-mexon)]

Sorry to write so much about this: this bug has literally cost me that much time. Here's me trying to boil down the logic to point form:

1. The UI can be in one of two states: A or B
2. The accelerometer can be in an infinite number of states, some combination of acceleration in three dimensions
3. There is a thing called "System X" which tries to determine the user's current desired orientation from the accelerometer
4. System X's output can be one of three states: A, B or UNKNOWN (i.e. flat)
5. Apps (lock screen counts as an app) can support being in state A, or state B, or both
6. The shell has to be in the same state as the current app
7. If the current app only supports one state, ignore System X and switch UI to that state
8. If the current app supports both states, and System X indicates A or B, switch UI to that state
9. But if System X indicates UNKNOWN, do not switch

Bonus point:

10. Whenever the UI changes from A to B or vice versa, switch all background apps that support both states, not just the current app

This bug is basically saying the system hasn't implemented point 9. I guess that's because System X, whatever that is, currently only supports two states rather than three.