This is screen orientation api - I think mlamouri@ would be the go-to person here

Is this not an issue that needs to be fixed?

Here's a video of the issue

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

This seems pretty bad! Is there no pop-up for apps to request usage of the screen orientation API first?

Locking screen orientation is only working on mobile. I'm surprised it's working on Windows. Re-assigning to aleksandar.stojiljkovic@intel.com who implemented the Windows backend.

+sky@ and cpu@ who reviewed it.

The original patch:
https://codereview.chromium.org/1758823004/

There are three issues identified here
1) problem that orientation changes with this specific hardware configuration (MS API states it shouldn't)
2) problem that orientation is not restored after browser process closes with this specific hardware configuration (MS API defines that it should and works properly for for all other HW tested).
3) Restoring happens when browser process closes (for HW platforms where 1&2 work properly). Instead, it should happen when tabs close.

In details:
1) problem that orientation changes with this specific hardware configuration (MS API states it shouldn't)
===============================================================
The code is using MS API: https://msdn.microsoft.com/en-us/library/windows/desktop/dn629268(v=vs.85).aspx
SetDisplayAutoRotationPreferences function:
Sets the screen auto-rotation preferences for the current process.

The API works properly on all the tested platforms:
a) Widows 10 in Bootcamp on Macbook pro with Intel Iris Pro 5200 (doesn't have NVidia GPU).
There it is not expected that API works. Console prints out this.
orientation.js:90 set orienation: portrait-primary
orientation.js:48 can not set orientation: DOMException: screen.orientation.lock() is not available on this device.(anonymous function) @ orientation.js:48

b) Ultrabook Yoga12 (Windows 8.1)
c) saw it running properly on Surface Pro Windows 8 (forgot the version)
in b&c) orientation rotates to portrait only in tablet mode - switch it to laptop mode, or close the process in tablet mode, it turns back to default orientation.

gman@,
For the fix, it would be good to understand what HW returns on your MacBook in this method:
https://cs.chromium.org/chromium/src/content/browser/screen_orientation/screen_orientation_delegate_win.cc?rcl=0&l=121
You could see the values for AR_STATE here:
https://msdn.microsoft.com/en-us/library/windows/desktop/dn629263(v=vs.85).aspx

Are you able to debug it in VisualStudio to get the value? Anyhow, the other API call (SetDisplayAutoRotationPreferences) shouldn't do anything for your hardware. Sorry, need to use some of your time here to try to find the best solution for this. Thanks.

Otherwise, if you got familiar with the code ad if you question why the code there is designed a bit too permissive - the idea was to cover 2 in 1 devices; process orientation is active on Windows only in tablet mode - once you switch it to laptop mode it turns back to landscape. However code allows setting preference in laptop mode and then it gets active only when in tablet mode.



2) problem that orientation is not restored after browser process closes...
=================================================================
@gman, if you verified that there is no browser process remained active (task manager) and following this:
SetDisplayAutoRotationPreferences function:
"Sets the screen auto-rotation preferences for the current process."
means there is a bug in your HW - closing browser restores system orientation preference.
This leads to  issue 3 :


3) Restoring happens when browser process closes (for HW platforms where 1&2 work properly). Instead, it should happen when tabs close.
=================================================================
Need to check the logic there - it should restore when browser process closes but when tabs close. This is system behavior - restoring to original when process with preference set closes so I need to make check in which process orientation delegate runs.

Marking as started for 3) waiting for response to figure out the approach for fixing 1&2 on gman@'s hardware only.

1) Okay so I asked a couple of other friends and they could not repo on other nvidia windows machines. One was Windows 10 + NVidia 960. The other was Windows 10 + NVidia 980 so maybe this only happens on MBP NVidia

2) As for my MBP I checked and Chrome did completely quit (I turned off all extensions and watched the task manager). Is it supposed to go back to landscape? I wouldn't expect a tablet to go back to landscape after exiting a portrait app. I guess I'm assuming my machine is acting like a tablet in this case

Unfortunately I'm not doing active Chrome dev so I don't have a debug chrome to run to check the value in screen_orientation_delegate_win.cc

3) As for tabs if one tab requests portrait and another tab requests landscape what happens (on a tablet). That seems like it has to be a per tab setting just like it's a per app setting for normal tablet apps. Each tab is effectively it's own app. It's certainly possible for multiple tabs to go fullscreen on both OSX and Windows. Though I don't know the UX for switching tabs on Windows tablets. 

Sorry for late reply on this.
1) Hope your bootcamp NVidia drivers are updated. The behavior looks like the driver issue as SetDisplayAutoRotationPreferences "sets the screen auto-rotation preferences for the current process."

2) >I wouldn't expect a tablet to go back to landscape after exiting a portrait app
If closing the portrait app (i.e. the app was forcing portrait regardless on device orientation) and if the tablet is in landscape position or the app that becomes active after is forcing landscape position, it should go to landscape.

3) This is still an open issue - orientation should be related to current document, not to browser. 

 

Short update:
The most annoying part of this bug is not related to Chrome code. Also it is happening on specific HW and SW combination only (on Bootcamp + Windows + specific NVidia on MBP).
This behavior is handled by OS (following the Windows API used) and there is nothing specific the chromium code is doing to invoke it.
So this part of bug is "wont fix".

The remaining part of the issue, that we can fix in Chromium:

> 3) This is still an open issue - orientation should be related to current document, not to browser. 

Windows API used and the code in chromium is adequate. The problem is in design: the code should not be executed in browser but instead in tab specific renderer process. Once the tab gets active or hidden, the OS is taking care of applying process settings and restoring to active process defaults.

Again, as the bug is combination of driver issue and this issue, it makes sense to split it but let's see how this would affect original behavior on this device only.

Fixed by reverting the functionality:
https://bugs.chromium.org/p/chromium/issues/detail?id=702435#c35