Fetching the posture type should be async?

[darktears]

As I'm working on the implementation of the spec inside Chromium (see WIP that I uploaded in https://chromium-review.googlesource.com/c/chromium/src/+/2985142/) it seems clear to me that navigator.devicePosture.type won't work.

On Android and Windows at the moment the posture is derived from the fold angle. In the future we may or not have a dedicated API to query the posture directly but that's what we have for now. On Android it means that we need to fetch the hinge angle from the OS and that's an async operation. On Windows there isn't any API to fetch the hinge angle but so far the foldable devices shipping expose a custom sensor that is basically exposing the hinge angle as well. Similar to Android this is a async operation that may not return immediately. We need to first ask the OS access to the sensor and then wait the readings. This is extremely similar to the generic sensors btw.

So I suggest we change navigator.devicePosture.type to something else with a Promise that we can resolve when the browser have the first information to be able to compute the posture.

@kenchris

[reillyeon]

How will this work for the CSS media query? Will the page start to render assuming 'no-fold' and then change layout when the actual fold angle is determined? Like window size this may be a property the renderer needs to be initialized with so that it is immediately available for layout. (I don't actually know exactly how window size is communicated to the renderer but whatever is done there is probably appropriate here.)

[darktears]

@reillyeon very good point. For the CSS MQ what you're describing would make sense. After all people opting in for this feature will have blocks for at least no-fold and some other posture in their CSS so if the MQ value changes then automatically things will work just fine (beside the "useless" relayout). The caveat when using navigator.devicePosture.type as specified is that you have to subscribe to changes in order to get the updates. Hopefully developers will do the right thing.

Some digging is needed...

[darktears]

Some other food for thought.

We may (or may not) see an OS API that will return the posture in a more synchronous manner say like the orientation of the device. In this case the browser do not derive the orientation using the accelerometer or gyro but just query the OS which has an always available orientation value (obviously using the same sensors but it's done in the background). As the posture will be determined using more than the hinge angle I'm hopeful that the OSes will support fetching the posture directly. Unfortunately I did not hear any official stance on that with Android, Windows 10 or even Windows 11. Even if such APIs were to be released we would be looking at 2022 at best (say Android 13 or a new version of Windows 11).

Now I personally think that navigator.devicePosture.type is more elegant than say navigator.getDevicePosture() (or whatever name) returning a Promise that would resolve when the posture is available. Also navigator.devicePosture.type will stay aligned with the orientation which is window.screen.orientation.type.

I'm personally not too concerned of the MQ triggering a relayout, if the OS APIs eventually land and browsers' implementation are updated, developers' code will work just fine and will not relayout anymore. However in the current state of affairs if we keep navigator.devicePosture.type we have to inform clearly that the posture may be determined asynchronously and developers must register to the change event. Again if the OS APIs were to land then the first call to navigator.devicePosture.type would work right away.

[kenchris]

On Android and Windows at the moment the posture is derived from the fold angle. In the future we may or not have a dedicated API to query the posture directly but that's what we have for now. On Android it means that we need to fetch the hinge angle from the OS and that's an async operation. On Windows there isn't any API to fetch the hinge angle but so far the foldable devices shipping expose a custom sensor that is basically exposing the hinge angle as well. Similar to Android this is a async operation that may not return immediately. We need to first ask the OS access to the sensor and then wait the readings. This is extremely similar to the generic sensors btw.

Why can't we cache these values instead? I mean if the site has access to the device posture, then it will be notified when it changes and then we can store the last value and always return the current one.

[darktears]

Why can't we cache these values instead? I mean if the site has access to the device posture, then it will be notified when it changes and then we can store the last value and always return the current one.

We can cache the value of the posture for sure. The problem is the initial call to the API, the browser doesn't have access to the posture yet until we access the sensors, get readings and determine the posture. From a browser implementation standpoint one alternative is to spin up the hinge sensor readings (on foldable devices only) regardless if a page will use the API or not so we always have a fresh value. Maybe at a lower resolution to keep battery usage low. I will have to discuss with the Chromium community about that.

As I commented the problem is only temporary until OSes get support for fetching the posture just like the orientation (and thus make it more efficient). But we're not guaranteed that support will ever come.

[darktears]

Closing as the chromium implementation is caching the value.