You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The presentation.receiver attribute is set by the receiving user agent (the user agent that runs on the "second screen") to an instance of the PresentationReceiver interface when the receiving browsing context is created. That attribute does not exist in the controlling browsing context in particular.
Its value will never change while the receiving browsing context exists. The PresentationReceiver instance will go away when the receiving browsing context goes away, but then I would expect presentation (and navigator) to go away as well. Or does that fail to account for something?
In short, the spec uses [SameObject] to mean "whenever the app running in the receiving browsing context gets the attribute, it will get the same object".
@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 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.
I think currently you can't even use [SameObject] for a nullable type, so that might be another problem.
OK, got it. The WebIDL spec says "The [SameObject] extended attribute must not be used on anything other than a read only attribute whose type is an interface type or object" and a "nullable type" is indeed something different: https://heycam.github.io/webidl/#SameObject
One thing that I missed in a previous comment (#365 (comment)) is that the receiving browsing context cannot create new auxiliary browsing contexts in practice, because the "sandboxed auxiliary navigation browsing context flag" is set. It may only create nested browsing contexts and I still don't see how the reference issue can occur with nested browsing contexts. The nullable type problem remains though.
Agreed that [SameObject] should be removed from navigator.presentation.receiver.
Agreed that the spec is not clear enough on the behavior of PresentationReceiver in nested browsing contexts. That should be raised separately; I see @tidoust filed #367 so let's discuss there.
Per #365 (comment), if there's an opportunity for script to run when the receiving user agent closes a receiving browsing context, then we should also discuss whether to fire a terminated event on connections on the receiver side. Filed #374.
Activity
tidoust commentedon Nov 14, 2016
@annevk could you clarify what seems wrong?
The
presentation.receiverattribute is set by the receiving user agent (the user agent that runs on the "second screen") to an instance of thePresentationReceiverinterface when the receiving browsing context is created. That attribute does not exist in the controlling browsing context in particular.Its value will never change while the receiving browsing context exists. The
PresentationReceiverinstance will go away when the receiving browsing context goes away, but then I would expectpresentation(andnavigator) to go away as well. Or does that fail to account for something?In short, the spec uses
[SameObject]to mean "whenever the app running in the receiving browsing context gets the attribute, it will get the same object".annevk commentedon Nov 14, 2016
It does. I can hold a reference to those objects while the browsing context could still go away.
tidoust commentedon Nov 14, 2016
Ah. How? What's the concrete set of steps that creates this possibility?
annevk commentedon Nov 15, 2016
@tidoust e.g., remove an
<iframe>.tidoust commentedon Nov 15, 2016
@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.receiverwill only be set in the top-level browsing context. It will always benullin nested contexts. But I suppose your comment equally applies towindow.open. If the receiving browsing context callswindow.openwith a same origin URL, the auxiliary browsing context could hold a reference to thePresentationinstance of the parent context with code such aslet 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 ofPresentationConnectionobjects, 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
terminatedwhen the receiving browsing context goes away. The termination algorithm 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 isterminated, 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.receivercould perhaps returnnullwhen the receiving browsing context goes away but I'm not clear what that gives us.annevk commentedon Nov 15, 2016
I think currently you can't even use [SameObject] for a nullable type, so that might be another problem.
I'm not suggesting it does I think. You might have bigger problems, for sure.
tidoust commentedon Nov 15, 2016
OK, got it. The WebIDL spec says "The [SameObject] extended attribute must not be used on anything other than a read only attribute whose type is an interface type or object" and a "nullable type" is indeed something different:
https://heycam.github.io/webidl/#SameObject
tidoust commentedon Nov 16, 2016
One thing that I missed in a previous comment (#365 (comment)) is that the receiving browsing context cannot create new auxiliary browsing contexts in practice, because the "sandboxed auxiliary navigation browsing context flag" is set. It may only create nested browsing contexts and I still don't see how the reference issue can occur with nested browsing contexts. The nullable type problem remains though.
markafoltz commentedon Nov 21, 2016
Agreed that
[SameObject]should be removed fromnavigator.presentation.receiver.Agreed that the spec is not clear enough on the behavior of PresentationReceiver in nested browsing contexts. That should be raised separately; I see @tidoust filed #367 so let's discuss there.
Per #365 (comment), if there's an opportunity for script to run when the receiving user agent closes a receiving browsing context, then we should also discuss whether to fire a terminated event on connections on the receiver side. Filed #374.