Re: dev-media Digest, Vol 26, Issue 12
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 jamie.mcdonn...@gmail.com 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 m...@mozilla.com wrote: On 2014-04-19, at 00:38, Jamie McDonnell jamie.mcdonn...@gmail.com 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: jamie.mcdonn...@eface2face.com | 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: jamie.mcdonn...@eface2face.com | 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
Re: dev-media Digest, Vol 26, Issue 12
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 m...@mozilla.com wrote: On 2014-04-19, at 00:38, Jamie McDonnell jamie.mcdonn...@gmail.com 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: jamie.mcdonn...@eface2face.com | 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 dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: dev-media Digest, Vol 26, Issue 12
On 2014-04-19, at 00:38, Jamie McDonnell jamie.mcdonn...@gmail.com 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. ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: dev-media Digest, Vol 26, Issue 12
This is the current error but it seems to have gone quiet - any progress on this: https://bugzilla.mozilla.org/show_bug.cgi?id=895971#c24 Thanks! On 17 April 2014 21:00, dev-media-requ...@lists.mozilla.org wrote: Send dev-media mailing list submissions to dev-media@lists.mozilla.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.mozilla.org/listinfo/dev-media or, via email, send a message with subject or body 'help' to dev-media-requ...@lists.mozilla.org You can reach the person managing the list at dev-media-ow...@lists.mozilla.org When replying, please edit your Subject line so it is more specific than Re: Contents of dev-media digest... Today's Topics: 1. Re: WebRTC Firefox OS demo (StevenLee) 2. Camera / Mic popup disappears when browser looses focus (Jamie McDonnell) -- Message: 1 Date: Thu, 17 Apr 2014 11:12:41 +0800 From: StevenLee s...@mozilla.com To: Sonny Piers so...@fastmail.net Cc: mozilla-dev-me...@lists.mozilla.org Subject: Re: WebRTC Firefox OS demo Message-ID: f657ea83-ddd0-4b2a-989a-2d1d8c64a...@mozilla.com Content-Type: text/plain; charset=utf-8 Hi Sonny, B2G turns on webrtc by default. Just clone and build. Steven On 2014/4/16, at ??10:32, Sonny Piers so...@fastmail.net wrote: Hi, We (upptalk.com) are going to show off PSTN/SIP interoperability with WebRTC at http://tadhack.com/2014/ We'd like to demo on a b2g device too, is there anything I should know before starting building b2g with webrtc flag? if it works best with a device or doesn't with this one, ... ? Also, anyone interested in joining us to show off Firefox OS? Cheers ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media -- Message: 2 Date: Thu, 17 Apr 2014 19:31:19 +0200 From: Jamie McDonnell jamie.mcdonn...@gmail.com To: dev-media@lists.mozilla.org Subject: Camera / Mic popup disappears when browser looses focus Message-ID: CAE6EhPTR3PMrM4hYKCW= skklz_tmv3cvtm-wqw_mh0kd7na...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Hi all, I have been fighting today with the issue of the allow camera / mic popup disappearing if firefox 28 looses focus after a getUserMedia query. No event is fired when this happens which makes it very tricky to react to in the UI. I have tried rigging up timers with focus / blur events to try and detect if this scenario has happened, but can not find a reliable approach. Has anyone overcome this issue, or Moz guys, is this in your pipeline to fix? The camera / mic box really should persist if the user switches app and back to the browser again. Cheers Jamie -- -- Jamie McDonnell | User Experience Design Evangelist and Developer | eFace2Face mobile: (+420) 777 608 442 | email: jamie.mcdonn...@eface2face.com | 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. -- -- Subject: Digest Footer ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media -- End of dev-media Digest, Vol 26, Issue 12 * -- -- Jamie McDonnell | User Experience Design Evangelist and Developer | eFace2Face mobile: (+420) 777 608 442 | email: jamie.mcdonn...@eface2face.com | 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
Re: dev-media Digest, Vol 26, Issue 12
On 2014-04-18, at 02:59, Jamie McDonnell jamie.mcdonn...@gmail.com wrote: This is the current error but it seems to have gone quiet - any progress on this: https://bugzilla.mozilla.org/show_bug.cgi?id=895971#c24 As noted in the bug, that issue is invalid. ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
