W3C home > Mailing lists > Public > public-secondscreen@w3.org > November 2016

Re: [presentation-api] [SameObject] for receiver seems wrong

From: François Daoust via GitHub <sysbot+gh@w3.org>
Date: Tue, 15 Nov 2016 10:33:14 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-260606105-1479205993-sysbot+gh@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 

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 
 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 
 using your GitHub account
Received on Tuesday, 15 November 2016 10:33:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:19:01 UTC