Another thought on this topic, I would be able to trap the moment where the browser looses focus after gUM is initiated and before onSuccess or onError was called if only the browser didn't loose focus when clicking into the door hanger - because this triggers focus and blur events it makes trapping window.blur after getUserMedia request and before onSuccess and onError impossible.
The gUM door hanger is in the context of the window - it relates ONLY to the content in that window, therefore should not trigger a blur event on the window object when clicked, as the user has not navigated away from the window. Please address at least one of these two issues in the browser so that we developers can build UI that follows a natural path for the user. Thanks! On 22 April 2014 10:30, Jamie McDonnell <[email protected]> wrote: > Hi Martin, > > thanks for the suggestions - in our app, you select if you want to connect > with video and audio, audio only or chat only - hitting "Allow" begins the > call connection. > > I can show a piece of UI where the door hanger should be (and yes I would > have to style and position it based on UA detection, not ideal) alerting > them to the fact that it has disappeared without them acknowledging it > > It would have to be shown only in FF when the user triggers gUM, and > hidden onSuccess. Seems like a clumsy work-around to a browser UI issue to > me (and many other developers of web apps), one that doesn't exist in > Chrome. > > Do you have an example of an app that has successfully dealt with this > issue in a manor that is clear and makes sense to users? If so I would very > much like to see it. > > Failing that, a method to trap the fact that the door hanger was hidden > due to the browser loosing focus by way of focus / blur events might help > put control back into the hands of developers in this instance. > > Thanks > > Jamie > > > On 21 April 2014 18:20, Martin Thomson <[email protected]> wrote: > >> >> On 2014-04-19, at 00:38, Jamie McDonnell <[email protected]> >> wrote: >> >> > what is the suggested approach for this scenario when a user alt-tabs >> away from the browser, or it looses focus while a gUM request is in >> progress? >> >> You can show an indicator in content that you are awaiting user input >> [1]. How is that not sufficient? >> >> Note that even if we were to provide an event in this scenario, we could >> not provide the application with any way to retrigger the door hanger for >> the aforementioned reasons. So I’m not sure that there is anything >> actionable from the application perspective. >> >> —Martin >> >> [1] I note that you could place this indicator in the area that the door >> hanger occludes if you only want it visible to users who had it lose focus. >> Though I note that requires UA detection, which is definitely undesirable. > > > > > -- > ------------------------------ > Jamie McDonnell | User Experience Design Evangelist and Developer | > eFace2Face > > mobile: (+420) 777 608 442 | email: [email protected] | web: > eface2face.com <http://www.eface2face.com> > [image: eface2face logo] <http://www.eface2face.com> > > [image: View our company profile on LinkedIn] > <http://www.linkedin.com/company/eface2face> > > This electronic communication and any files transmitted with it, or > attached to it, are confidential and are intended solely for the use of the > individual or entity to who it is addressed and may contain information > that is confidential, legally privileged, protected by privacy laws, or > otherwise restricted from disclosure to anyone else. If you are not the > intended recipient or the person responsible for delivering the e-mail to > the intended recipient, be advised that you have received this e-mail in > error, and that any use, dissemination, forwarding, printing, or copying of > this e-mail is strictly prohibited. If you received this e-mail in error, > please return the e-mail to the sender, delete it from your computer and > destroy any printed copy of it. Although our company attempts to sweep > e-mail and attachments for viruses, it does not guarantee that either are > virus-free and accepts no liability for any damage sustained as a result of > viruses. > ------------------------------ > -- ------------------------------ Jamie McDonnell | User Experience Design Evangelist and Developer | eFace2Face mobile: (+420) 777 608 442 | email: [email protected] | web: eface2face.com <http://www.eface2face.com> [image: eface2face logo] <http://www.eface2face.com> [image: View our company profile on LinkedIn] <http://www.linkedin.com/company/eface2face> This electronic communication and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to who it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, be advised that you have received this e-mail in error, and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer and destroy any printed copy of it. Although our company attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. ------------------------------ _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
