How can receiver always return the same object? What happens when the browsing context goes away?

@annevk could you clarify what seems wrong?

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".

Or does that fail to account for something?

It does. I can hold a reference to those objects while the browsing context could still go away.

Or does that fail to account for something?

It does. I can hold a reference to those objects while the browsing context could still go away.

Ah. How? What's the concrete set of steps that creates this possibility?

@tidoust e.g., remove an <iframe>.

@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.

What I do not understand is how dropping [SameObject] could help fix that problem.

I'm not suggesting it does I think. You might have bigger problems, for sure.

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.