- From: engedy via GitHub <sysbot+gh@w3.org>
- Date: Mon, 18 Feb 2019 13:14:41 +0000
- To: public-geolocation@w3.org
Indeed, restricting `DeviceMotionEvent` and `DeviceOrientationEvent` to `[SecureContext]` serves the purpose of allowing pre-existing feature detection code -- such as `"DeviceMotionEvent" in window` or `typeof DeviceMotionEvent` or `!!window.DeviceMotionEvent` -- to correctly detect this new restriction: ``` if (!!window.DeviceMotionEvent) { window.ondevicemotion = function() { .... } } else { // Do other cools things instead. } ``` My initial PR did not restrict `ondeviceorientation` and `ondevicemotion` to secure contexts because @mikewest and I were concerned that doing so could break sites; and we wanted to take a more gentle approach where we would still expose the attributes and allow registration, just never fire the registered event handlers. However, in the meantime we realized our fears were unfounded, as we could not come up with -- nor observe in the wild -- any event handler registration patterns that would be actually broken by removing the attributes. So my updated proposal is to mark all interfaces/attributes as `[SecureContext]` in the spec, while possibly allowing user agents to keep the event attributes around (without ever firing the handlers) so that they can issue console warnings should web applications still try to register event handlers in spite of `DeviceOrientationEvent` and friends no longer being around. WDYT? -- GitHub Notification of comment by engedy Please view or discuss this issue at https://github.com/w3c/deviceorientation/pull/65#issuecomment-464727279 using your GitHub account
Received on Monday, 18 February 2019 13:14:42 UTC