Intent to Implement: Fullscreen Media Orientation

[Mounir Lamouri]

Contact emails

dalec...@chromium.org, mlam...@chromium.org, renga...@chromium.org

Spec

No spec change.

Summary

Maximize the screen usage when a <video> goes fullscreen, either directly via the Fullscreen API or via the default media controls. It will not apply to typical custom controls implementations where a wrapper <div> around the <video> is requested to go fullscreen.

To achieve this, Chrome will automatically change the orientation of the video to match the aspect ratio of the video. If video is wider than taller, then chrome will change (and lock) orientation to landscape; If video is taller than wider, then chrome will change (and lock) orientation to portrait.

Motivation

According to Chrome’s metrics, two thirds of the time, when a video goes fullscreen, the users rotate their phone.

Interoperability and Compatibility Risk

This is not a new API but a change in default UA behaviour. Therefore, the interoperability risks are low. A website will be notified of an orientation change when the lock will happen which shouldn’t be differentiable from a user rotating their device. The lock will also interfere with a possible lock from the page. In order to mitigate that concern, the screen orientation will not be locked if the frame made a lock request and did not explicitly unlock yet.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Android only.

OWP launch tracking bug

https://crbug.com/670455

Link to entry on the feature dashboard

https://www.chromestatus.com/features/6063407807594496

Requesting approval to ship?

No. But it should happen soon-ish.

[mark a. foltz]

On Mon, Dec 5, 2016 at 9:28 AM, Mounir Lamouri <mou...@lamouri.fr> wrote:

Contact emails

dalec...@chromium.org, mlam...@chromium.org, renga...@chromium.org

Spec

No spec change.

Summary

Maximize the screen usage when a <video> goes fullscreen, either directly via the Fullscreen API or via the default media controls. It will not apply to typical custom controls implementations where a wrapper <div> around the <video> is requested to go fullscreen.

To achieve this, Chrome will automatically change the orientation of the video to match the aspect ratio of the video. If video is wider than taller, then chrome will change (and lock) orientation to landscape; If video is taller than wider, then chrome will change (and lock) orientation to portrait.

Motivation

According to Chrome’s metrics, two thirds of the time, when a video goes fullscreen, the users rotate their phone.

Interoperability and Compatibility Risk

This is not a new API but a change in default UA behaviour. Therefore, the interoperability risks are low. A website will be notified of an orientation change when the lock will happen which shouldn’t be differentiable from a user rotating their device.

Is the UA-initiated lock propagated via the orientationchange event?

 

The lock will also interfere with a possible lock from the page. In order to mitigate that concern, the screen orientation will not be locked if the frame made a lock request and did not explicitly unlock yet.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Android only.

Why Android-only?  Are PC or Chrome OS convertibles not a use case for this as well?

m.

[PhistucK]

The only aspect that disturbs me here is the locking... While in most of the cases, people do want to see the video on the entire screen, having it in a smaller part can (I guess) save some battery. I would argue that an unlock button (or a setting, but I must be dreaming ;)) is needed for the user.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Mounir Lamouri]

On Tue, 6 Dec 2016, at 07:58, PhistucK wrote:
> The only aspect that disturbs me here is the locking... While in most of
> the cases, people do want to see the video on the entire screen, having
> it
> in a smaller part can (I guess) save some battery. I would argue that an
> unlock button (or a setting, but I must be dreaming ;)) is needed for the
> user.

I would be surprised if rendering the video is a smaller part of the
screen would have a significant impact on the battery usage but I didn't
check :) We are considering a way for users to opt-out in a way or
another but that would be for a later release. It's unclear if it would
be using device rotation (sensors) or an opt-out button.

Worth noting that the reason why this is locking this screen orientation
is that we can't ask Android to draw the application in a specific
orientation without locking (which makes sense really). The alternative
would be to draw the video with a 90 degrees rotation but that would
make the whole system UI look odd (the notification bar would be at the
wrong place).

> > *Interoperability and Compatibility Risk*

> >
> > This is not a new API but a change in default UA behaviour. Therefore, the
> > interoperability risks are low. A website will be notified of an
> > orientation change when the lock will happen which shouldn’t be
> > differentiable from a user rotating their device.
> >
>

> Is the UA-initiated lock propagated via the orientationchange event?

If it results in an orientation change, yes. The same way a user
rotating the device would produce an orientation change.

> > *Will this feature be supported on all six Blink platforms (Windows, Mac,
> > Linux, Chrome OS, Android, and Android WebView)?*

> >
> > Android only.
> >
>
> Why Android-only? Are PC or Chrome OS convertibles not a use case for
> this
> as well?

For Windows, I'm not sure if Chrome can easily make the difference
between a convertible and a non-convertible. Maybe Chrome OS has this
information? I wouldn't consider this a priority but maybe something to
consider for the Chrome OS team.

-- Mounir

[Wez]

Comments in-line, below.

It looks like switching between tablet and non-tablet modes is notified via a WM_SETTINGSCHANGE message, FWIW.

Will we need some special-casing for split-screen modes even on tablet/phone devices?

-- Mounir

[mark a. foltz]

Another example: if someone has a docked Pixel C they probably won't want this behavior.

m.

[Mounir Lamouri]

Correct. And sorry for not following up on your comment Wez. The feature
will only be enabled on phones. Later versions will have an escape
mechanism.

-- Mounir

[Wez]

My comment was in reponse to Mark F's querying whether we should plan for support on convertibles (e.g. Chromebook Flip, Yoga devices); it sounds like the answer is that yes, we should do that, but that our first implementation will be for Android phones only.

[Mounir Lamouri]

That is correct and thank you for clarifying :) For devices with a
larger form factor, the feature would be interesting but having an
escape would probably be mandatory because the need seem less obvious.
Our metrics show a lower screen rotation when a video is fullscreen'd on
Android tablets compared to Android phones for example. We believe that
the need on mobile is strong enough to ship in multiple steps.

-- Mounir

> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to blink-dev+...@chromium.org.

[Aleksandar Stojiljkovic]

> to achieve this, Chrome will automatically change the orientation of the video to match the aspect ratio of the video. 

For Windows, code in screen_orientation_delegate_win.cc might be usable.

SetDisplayAutoRotationPreferences [1] would set the per process preference and one the process(tab) is not active system restores default.

Note that the API should be call in chromium tab related process.

Also, the call is noop on desktop - should work only on Windows tablets and 2-in-1 when in tablet mode.

To get the state if there is sensor, if it is in laptop or docked mode, etc... to see if it is possible or needed to change orientation, call GetAutoRotationState [2].

 

[1] 

https://cs.chromium.org/chromium/src/content/browser/screen_orientation/screen_orientation_delegate_win.cc?rcl=0&l=14

[2]

https://cs.chromium.org/chromium/src/content/browser/screen_orientation/screen_orientation_delegate_win.cc?rcl=0&l=121

Kind Regards,

Aleksandar

[mark a. foltz]

Non-owner LGTM for shipping on phone form factors first :)

> email to blink-dev+unsubscribe@chromium.org.

[Wez]

+1 to that - thanks for confirming the path to other platforms, Mounir. :)