Issue 706354  has been merged into this issue.

Just FYI, I retested this today, and it's still broken:

Platform: 9592.29.0 (Official Build) beta-channel kevin
Chrome: 60.0.3112.41 (Official Build) beta (32-bit)

It has actually never worked. I've spoken with girard@ who will be running some upcoming work in this space about why. Hopefully we'll have a resource who can fix this.

I'll document that here:

When you log in we spin up a new ash::Shell which handles all of the UI work. This is where the tablet mode logic lives. So there is currently no setup to preserve tablet mode state between the login screen and the logged in state.

We had considered earlier on in writing the screen orientation out to disk when swapping login state. However this would involve a disk write, and we'd end up racing the teardown of Ash.

Most of the time a device in tablet mode would be interacted while held, or in a tent/stand configuration, the majority of login state changes would occur when we have reliable accelerometer data to determine screen orientation. Due to this we didn't pursue creating a method to handle the case of the device being flat on a table.

(Anecdotally: I can guarantee that I've set large tablet-mode devices flat on a table at the login screen just so I can painfully type in my password.)

Does comment #7 imply you've fixed the "Alternatively, skip step (4)" behavior in the OP? I noticed I can't seem to reproduce that any more; if I have the device tilted enough when logging in, the new session starts up fine, with no glitchy back-and-forth.

If the device is not flat as in Step 4) in #1 there is still a race as the tablet mode code is being brought up.

However some other work done in the past few months would have greatly reduced the time frame where it can occur. The lower level EC portion which knows the hinge angle is able to talk with Chrome now at startup. So tablet mode logic can be ran most often before UI is rendering.

Just thought I'd swing by, since I tried to use devices today in touchview orientation, in a perfectly natural sitting position, with my device on my lap somewhere between 5 and 15 degrees angle (estimated). It's very disorienting seeing this change when I log in. My experience goes something like:

1. Have device situated in non-default orientation (e.g., portrait mode on a landscape-default device)
2. Take an update; reboot
3. See device boot up in the opposite mode
4. Shake device around until it remembers that it's tilted slightly toward portrait
5. Return to lap; log in
6. See device log in in opposite orientation again
7. Repeat step 4
8. Log in to chromium.org account to post about your frustrating experience
9. Notice that you're starting to describe everything you're doing, including typing this comment. When does it stop?

Or TL;DR: there are definitely use cases that trigger this bug without actually leaving a device flat on a table.

Are we going to have to bite the bullet and write some state out to disk? Or better yet, we could have a proper daemon (i.e., not Chrome) handle rotations, and retain this information in memory. It's not exactly secret, user-sensitive data to know that the device is logically rotated one way or the other.

> 5. Return to lap; log in
> 6. See device log in in opposite orientation again

The orientation should stay the same after login.

Did the chrome restart when you login ? (can happen when you use guest mode, or you have custom about:flags)

oops, hit save too eary.

.. or there could be a regression. Please file a separate bug if that's the case.

> The orientation should stay the same after login.

I thought #9 acknowledged that "laying flat" is still an open bug. I was just noting that "flat" is a loose term, and it appears that common use cases (like "slightly angled, on my lap") qualify.

> Did the chrome restart when you login ?

Not as far as I can tell.

> (can happen when you use guest mode, or you have custom about:flags)

It's a proper login (not Guest), but I do have a custom flag or two. I can check again without these flags.

#10's report was on canary (M62, 9798.0.0), with some custom flags.

I retried after setting about:flags back to defaults, then restarting Chrome and logging in/out a few times. Same behavior.

I also tried on a device I have beta on (M60, 9592.71.0) with no custom flags. It seemed to carry over on login. But not on logout.

So maybe part of this is a regression? But it was never "fixed".

I also don't understand from a feature point of view why Guest mode, or about:flags should make any difference. In *all* cases, rotation should be remembered. That sounds like it might be impossible with the current design.

> I also don't understand from a feature point of view why
> Guest mode, or about:flags should make any difference.

I wouldn't argue that it *should* work like this, but Oshima's point was just that we restart Chrome (by design; see e.g. issue 463910, issue 649405, issue 681278) when entering guest mode or dealing with custom flags set by a non-device-owner, so if that's happening it's more work to preserve the old state.

Accelerometer data is collected within Chrome instead of getting IPC-ed to it due to the frequency with which we need to collect it (every 100 ms, IIRC). Maybe that could change when/if we use Mojo instead of D-Bus for IPC with system daemons.

Per #7, it sounds like we could just pass the orientation to the new ash::Shell after login, right? We could presumably additionally handle the guest mode and custom flag cases by having Chrome write the orientation to Local State or /run or somewhere similar when it exists, although I don't know if it's worth the added complexity.

Yes, we're not arguing about guest mode behavior is correct (It's basically the same issue as this bug).
We're trying to understand if what you're seeing is a new issue, or the same issue as this bug.

> I retried after setting about:flags back to defaults, then restarting Chrome and logging in/out a few times. Same behavior.

Please file a separate bug if chrome forgets the tablet mode and orientation after login with
default flags settings.

Please include your versions as well. I tested on 62.0.3173.0 / 9788.0.0 and the orientation stays the same after login in tablet mode, so if there was a bug in previous versions, but it has fixed recently
we need to make sure that the fix is merged.

> Please file a separate bug if chrome forgets the tablet mode and orientation after login with default flags settings.

AFAICT that's not happening. But that's not sufficient IMO.

Today, I'm running canary 9889.0.0-17.08.29 (Chrome 62.0.3199.0). The following transitions are broken (i.e., don't retain rotation):

1. Login screen -> Guest mode
2. Logged in (Guest or regular account) -> Logout
3. Login screen -> Logged in (with non-default chrome://flags)

This works fine AFAICT:

4. Login screen -> Logged in with regular account (default chrome://flags)

Bump? Still verified the problem exists for Guest login/logout, at least:

OS: 10082.0.0
Chrome: 64.0.3253.0

If you're only seeing this for the three cases described in #18, then it sounds like the problem is just triggered when Chrome restarts.

I don't know that we have any standard mechanism to pass state to a restarted Chrome process. If I were forced to speculate about the easiest (hackiest) way to do this, I'd probably say that we could write a file somewhere under /run that Chrome can read after restarting. That's in-memory, IIRC, so there shouldn't be any concerns about disk writes.

Albert, opinions about if/when someone can look into adding this or something similar?

> If you're only seeing this for the three cases described in #18, then it sounds like the problem is just triggered when Chrome restarts.

Yes, sounds right. (The only discrepancy in the original title was that I didn't understand at first that "non-default chrome://flags" implied "Chrome restart on login".)

> write a file somewhere under /run that Chrome can read after restarting. That's in-memory, IIRC

# mount
...
run on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,seclabel,mode=755)
...

So yes, that's in memory. Not sure if we rely on that sort of things for functional correctness though. There are also other considerations besides just "last state", of course, like current lid angle and sensor orientation. But if nothing else is determining the orientation, the "last state" saved to the filesystem sounds right to me.

#20, you need to save on disk to remember the orientation after shutdown/battery drained. The amount of write (max(once per rotation, 10 minutes write cache sync) is not that bad.

#24: We should explicitly *not* persist this across reboot. If the system shuts down in one orientation, why should we assume that it's still in the same orientation the next time it boots? I mostly care about the case where Chrome restarts, because that should take a few second tops.

Yes, we should remember it only when the chrome restarts (due to crash, logout , restart from chrome:flags).

It can just also be in local state (like other display settings),
and chrome can ignore it when -first-exec-after-boot is set upon switching to tablet.