Re: Draft algorithms specification

>
>
>>      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:19 UTC