- From: Anton Vayvod via GitHub <sysbot+gh@w3.org>
- Date: Thu, 28 May 2015 16:50:53 +0000
- To: public-secondscreen@w3.org
@obeletski please, read the original description of this issue, it has a brief summary and some links to mailing list discussions. From the meeting notes: ``` Mark_Watson: So, startSession handles this, but some way to monitor available screens in the background would be pretty useful. Problem is enabling continuous monitoring when an event handler is attached to a property is considered bad practice, right? Mark_Foltz: right. Anssi: Adding an event listener should not have side effect, that's a shared practice. Mark_Foltz: So, how does geolocation handle this? Anssi: Example of the deviceOrientation. If your phone is staying flat and you attach an event listener, you will not get an event up until the phone moves. The spec cannot force the user agent to fire an event when the event listener is attached. ``` Now imagine the following scenario: the UA started running background availability monitoring of second screens because page A attached a listener to |onavailablechange|. The UA finds the screens and fires an event - page A knows there're screens available. Then page B is loaded by the user and it attaches its own listener - if the UA follows good practices of implementing events, it will not fire the event to page B because the availability state hasn't changed. But page B doesn't know the current state so it will assume there's no devices available. The common practice is to provide a current state property - which is what the first proposal is about. If we follow the second proposal - the page would have to wait until the promise resolves and attach a listener only then. Otherwise it would get both the promise resolved and event firing depending on when it attached the listener. As long as the page attached a listener, it doesn't matter if there's a property we have to update in runtime. There's a way to stop background discovery if the page cares (detach the event listener and abandon the reference to the AvailabilityListener) but I would expect most of the pages won't and would rely on the browser to optimize the battery and performance for them. -- GitHub Notif of comment by avayvod See https://github.com/w3c/presentation-api/issues/81#issuecomment-106483395
Received on Thursday, 28 May 2015 16:51:08 UTC