- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Thu, 26 Feb 2015 15:33:36 +0000
- To: "public-media-capture@w3.org" <public-media-capture@w3.org>
My conclusion of this thread: * application developers want this feature (and they have a preference for "cancel" mechanism over a timeout) * however, introducing this should be coordinated with other groups, and will take time Given that we are trying to move to Last Call soon, I think we should not let this block LC, but instead resolve this after Last Call. Stefan On 19/02/15 16:55, Erin Spiceland wrote: > Either #2 or #3 would be good for us. We'd prefer #3 so that we can > cancel based on user input. > > On Thu, Feb 19, 2015 at 8:31 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote: >> 2015-02-19 15:25 GMT+01:00 Harald Alvestrand <harald@alvestrand.no>: >>> Our alternatives include: >> >>> - Not doing anything, letting apps deal with the issues as described >>> above, or living with it >> >> >From my experience I do not like that no-solution because indeed it >> fixes nothing :) >> >> >>> - Adding a timeout parameter to getUserMedia, which allows the prompt to >>> fade away after a while >> >> Don't like. Better let the app to use its own setTimeout and call >> cancel() as the bullet below suggests. >> >> >>> - Adding a "cancel" mechanism wehre a the gUM promise can be resolved by >>> the Javascript not the platform, leading to the prompt disappearing >> >> Like it. >> >> >> getUserMedia() may return something (regardless it is Promise based or >> not), so we could do: >> >> var gUM = navigator.getUserMedia(........); >> >> navigator.clearGeUserMedia(gUM); >> >> >> Similar to clearTimeout() and so on. >> >> >> >> >> -- >> Iñaki Baz Castillo >> <ibc@aliax.net> >> > > >
Received on Thursday, 26 February 2015 15:34:06 UTC