> > >> 7.6 Session Close >>> ----- >>> What is the purpose of step 4? Why is it not enough to "queue a task >>> to fire an event named statechange at S.onstatechange" given that S >>> is known right from the start? >>> >>> >>> That was a long winded attempt to ensure that all pages connected to a >>> session get the event. I agree this should be simplified and explained >>> that events fired on a PresentationSession are sent to all pages that >>> currently hold a reference to it. >>> >> >> Hmm, I assumed there would be only one page holding a reference to a >> session at a time. Is that not the case? >> > > That's correct but there could be multiple sessions that are connected to > the same presentation (via join). > > >> >> In other words, I thought different tabs would have different sessions >> objects, so that a call to "close" issued in one tab would not have any >> effect on a similar session running on another tab. >> >> By the way, shouldn't closing a session also remove the corresponding >> entry from set D? >> > > Has the semantics of close() been discussed in the CG or WG yet? It could > mean one of three things: > > (1) Disconnect this PresentationSession (and only this > PresentationSession) from the presentation. > (2) Disconnect all PresentationSessions known by this user agent from the > presentation. > (3) Request that the second screen cancel the presentation (and, if > successful, will result in #2). > > We can go with (1), which is the most conservative approach, but doesn't > give a page any way to actually stop a presentation itself. Either the > user agent would provide a mechanism, or it could message the presentation > document to call window.close(). I'm fine with that approach (it's > consistent with the UX we have for Cast) but I'm curious to hear other > thoughts. > Clarification: or *the connected document* could message the presentation document to call window.close() m.
Received on Friday, 9 January 2015 19:51:20 UTC