- From: François Daoust via GitHub <sysbot+gh@w3.org>
- Date: Tue, 15 Nov 2016 10:33:14 +0000
- To: public-secondscreen@w3.org
@annevk So, I see something wrong but I'm not sure that's the problem you're raising here ;) The spec may not be clear about nested contexts on the receiving side but `navigator.presentation.receiver` will only be set in the top-level browsing context. It will always be `null` in nested contexts. But I suppose your comment equally applies to `window.open`. If the receiving browsing context calls `window.open` with a same origin URL, the auxiliary browsing context could hold a reference to the `Presentation` instance of the parent context with code such as `let pres = window.opener.window.navigator.presentation`, and that reference will survive the closing of the parent context. That auxiliary browsing context could then access the list of `PresentationConnection` objects, even after the parent context is closed. Is that the situation that you have in mind? The problem for me is that the spec does not say that the state of presentation connections should be changed to `terminated` when the receiving browsing context goes away. The [termination algorithm in a receiving browsing context](https://w3c.github.io/presentation-api/#dfn-terminate-a-presentation-in-a-receiving-browsing-context) only asks the receiving user agent to send a termination request to the controlling side. It should do that because the auxiliary context could hold a direct reference to a presentation connection as well. If the connection state is `terminated`, the objects that the auxiliary context may have references to should be mostly "inert". What I do not understand is how dropping `[SameObject]` could help fix that problem. `presentation.receiver` could perhaps return `null` when the receiving browsing context goes away but I'm not clear what that gives us. -- GitHub Notification of comment by tidoust Please view or discuss this issue at https://github.com/w3c/presentation-api/issues/365#issuecomment-260606105 using your GitHub account
Received on Tuesday, 15 November 2016 10:33:21 UTC