- From: Rottsches, Dominik <dominik.rottsches@intel.com>
- Date: Mon, 12 Jan 2015 12:34:59 +0000
- To: "mfoltz@google.com" <mfoltz@google.com>
- CC: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, "fd@w3.org" <fd@w3.org>, "public-secondscreen@w3.org" <public-secondscreen@w3.org>, "public-webscreens@w3.org" <public-webscreens@w3.org>, "avayvod@google.com" <avayvod@google.com>, "markdavidscott@google.com" <markdavidscott@google.com>
On Fri, 2015-01-09 at 11:48 -0800, mark a. foltz wrote: > Has the semantics of close() been discussed in the CG or WG yet? Not sufficiently - I do agree we need to fill in the expected behavior for tearing down sessions. > 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. On the Intel side, we might need to gain a bit more experience from the implementation before we can have a final answer. However, I tend to think (3) would be the more meaningful definition of close(). Isn't close() as defined in (1) more or less a no-op? Can't you just discard the PresentationSession object and achieve the same? In (2), I see an issue with counterintuitive crosstalk to other tabs. If I understood your suggestion correctly, that would mean, that another tab (from the same origin probably) can disconnect the PresentationSession browser wide - and when switching to another tab that held a previously connected PresentationSession, it might now find itself disconnected, even though the content is still displayed. Sending a "please call window.close()" message on the MessagePort level is slightly less reliable, in my opinion, than sending that on the native side: The receiving end JS might be stuck or have parsing errors etc. and not process the request to close. This is why I think (3) would be the more useful definition. Regards, Dominik >
Received on Monday, 12 January 2015 12:35:33 UTC