- From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
- Date: Thu, 8 Nov 2012 15:32:35 +0200
- To: ext David Bruant <bruant.d@gmail.com>
- Cc: ext Marcos Caceres <w3c@marcosc.com>, ext Justin Lebar <jlebar@mozilla.com>, "DAP public-device-apis@w3.org" <public-device-apis@w3.org>
On 7.11.2012, at 14.44, ext David Bruant wrote: > Le 07/11/2012 13:12, Anssi Kostiainen a écrit : >> >> [[ >> >> Note >> >> A trusted (also known as privileged) application that integrates closely with the operating system's functionality may vibrate the device even if such an application is not visible at all, and thus may ignore the previous step. >> >> ]] All - I added the above note to the spec, let me know if you have concerns with that. [...] >> Justin, David, Marcos - does that change make sense to you? > It does and it could be enough. > It's not absolutely, but I would add that trusted/privileged app can cancel "regular" app vibrations even if the app is visible. In a nutshell, even if a trusted app is in the background/hidden, it can cancel visible apps vibration. That is what would happen as per the step 8, if the trusted app ignores the step 6 as per the note. > I would also assume that when a trusted app vibrates, if a visible app tries to vibrate, it will not work? > If no, it may be important to add this to the note under step 7 as an additional cause of potential failure. I'd be interested in knowing how other platforms handle such a race condition between system apps and other apps using a shared resource. Anyone? If this varies, I propose we leave that as an implementation detail. -Anssi
Received on Thursday, 8 November 2012 13:33:17 UTC