- From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
- Date: Wed, 16 Nov 2011 10:57:17 +0200
- To: ext Deepanshu gautam <deepanshu.gautam@huawei.com>
- Cc: ext Justin Lebar <jlebar@mozilla.com>, Jonas Sicking <jonas@sicking.cc>, "public-device-apis@w3.org" <public-device-apis@w3.org>, "public-device-status@w3.org" <public-device-status@w3.org>
On 16.11.2011, at 9.49, ext Deepanshu gautam wrote: > Sorry for coming to it bit late... > > About the added Step 9 "An implementation may abort the algorithm at this point". > I don't think abort is the only feasible option. There is always a functionality at native layer to disable the Vibrator i.e user may switch it OFF. So in this case won't it be suitable to first know whether the Vibrator is OFF? If it is, then user may be given an option to switch it on for specific time or for particular page/application? > To achieve this we just need a method like VibState() returning constants like "VibON" or "VibOFF". Depending on which it can be ascertained whether to continue to step 10 or abort. > > Note: Vibrator may be switched OFF by default, or it may be accidently switched OFF. So, it is worth for developers to try to get it ON for better user experience. Such a method would increase fingerprinting surface which is a privacy concern, so I'd prefer to not to include it. Couldn't the web app just ask the user to turn on the vibrator via the OS if needed, similarly to the way the volume control behaves? I.e. there's no way a web app can figure out if the device is muted, and the volume control is managed by the OS. This is the model users already understand, so I think we should reuse it. Do you agree? -Anssi
Received on Wednesday, 16 November 2011 08:58:27 UTC