What do you think about saying in the summary that we're hoping to
deprecate default access to window.ondevice{motion,orientation} in the
future?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
816-678-7195
*If an API's not documented it doesn't exist.*
On Tue, Jun 21, 2022 at 1:57 PM Raphael Kubo da Costa <
raphael.kubo.da.co...@intel.com> wrote:
> Correct. The larger plan is to:
> - Require requestPermission() before window.ondevice{motion,orientation}
> start dispatching events
> - Change the UI side to prompt for sensor access when necessary
> - Do the same as part of Sensor.start() (meaning Accelerometer.start() etc)
>
> How to get there without breaking websites that do not use
> requestPermission() is something we are still working out and that will not
> happen in the short term.
>
> On 21-06-2022 19:45, Joe Medley wrote:
>
> "these new functions are part of the plan to start prompting for access in
> the future."
>
> Can I assume this means you're going to deprecate default access
> to window.ondevice{motion,orientation} at some point?
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Mon, Jun 20, 2022 at 6:15 AM Raphael Kubo da Costa <
> raphael.kubo.da.co...@intel.com> wrote:
>
>> Contact emails raphael.kubo.da.co...@intel.com, eng...@chromium.org,
>> reil...@chromium.org
>>
>> Explainer None
>>
>> Specification https://w3c.github.io/deviceorientation
>>
>> Summary
>>
>> Allows developers to ask for permission to start using the Device
>> Orientation and Device Motion APIs. Access to these APIs is currently
>> granted by default, and these new functions are part of the plan to start
>> prompting for access in the future.
>>
>>
>> Blink component Blink>Sensor>DeviceOrientation
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESensor%3EDeviceOrientation>
>>
>> Motivation
>>
>> The Device Orientation spec is more than a decade old, at a time when
>> integration with the Permissions spec was not common (or possible). As
>> such, developers can use the window.ondevice{motion,orientation} events
>> without having to ask for permission before reading sensor data. A few
>> years ago, the WebKit team added the requestPermission() functions to
>> DeviceOrientationEvent and DeviceMotionEvent when implementing the spec, so
>> that websites would have to ask for permission before being able to use the
>> API. This is the case on Safari for iOS at the moment. We want to do the
>> same thing and avoid allowing websites access to sensor data by default.
>> Doing this in Chromium is more complicated because the API is already
>> implemented, and requiring developers to add requestPermission() to their
>> websites out of the blue can risk breaking the web. In this first step, the
>> idea is to just add the API and make it report "granted" or "denied"
>> without prompting for access (i.e. it just reports the current Motion
>> Sensor permission settings) while also adding user counters to understand
>> how many pages are already using the requestPermission() calls and how many
>> pages are just using window.ondevice{motion,orientation} without it. We
>> will then evaluate how to switch to prompting by default in the future, as
>> discussed in the tracking bug.
>>
>>
>> Initial public proposal
>>
>> Search tags device orientation
>> <https://chromestatus.com/features#tags:device%20orientation>, device
>> motion <https://chromestatus.com/features#tags:device%20motion>
>>
>> TAG review
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> *Gecko*: Under consideration (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1536382)
>>
>> *WebKit*: Shipped/Shipping (
>> https://bugs.webkit.org/show_bug.cgi?id=195329)
>>
>> *Web developers*: No signals
>>
>> *Other signals*: Lots of comments in the Chromium tracking bug over the
>> years
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>>
>> Debuggability
>>
>> -
>>
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ? Yes (as part of the CL I am working on)
>>
>> Flag name
>>
>> Requires code in //chrome? False
>>
>> Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=947112
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5051845089689600
>>
>> This intent message was generated by Chrome Platform Status
>> <https://chromestatus.com/>.
>> --
>> 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+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a7bfbf70-0cbf-709f-6310-7af1101c2574%40intel.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a7bfbf70-0cbf-709f-6310-7af1101c2574%40intel.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJUhtG9L-GAf9%2Bo2G8YB69cz%2BoHC3NSdpgpaMZo-6F0Xgm9Xgg%40mail.gmail.com.
