Re: User agent context for rendering the presentation

On Wed, Aug 20, 2014 at 6:49 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Wed, Aug 20, 2014 at 6:06 PM, Mark Watson <watsonm@netflix.com> wrote:
> > So, I'm no so much interested in whether it uses an existing Presentation
> > API session or not. Let's just assume it doesn't.
> >
> > So the browser on the TV is freshly navigated to www.netflix.com. What I
> > meant by the TV being logged in to Netflix account N9 is that cookies,
> > IndexedDB data etc. for www.netflix.com is present indicating that it is
> > logged in. It would then be the sites decision, when launched in
> > presentation mode and after communicating with the controller, whether to
> > stay logged in on that Netflix account or log in on the same Netflix
> account
> > as the controller. I would very much like to be able to handle the case
> > where the controller is using the same Netflix account as the TV without
> > having to do a new Netflix log-in.
> >
> > So, I'm saying that IndexedDB, if supported, should not be cleared each
> time
> > a new presentation session starts.
>
> I think this falls under the umbrella of "connecting to applications
> already installed on a TV".
>

​No, I'm just addressing the straightforward 2 UA case and the question -
which I thought was the subject of this thread - about whether the browsing
context at the "presenting" UA is a "fresh" one (like incognito mode) or
might have previously stored data ​for that origin.

It had been suggested that we mandate something like incognito mode, where
IndexedDB etc. are cleared on the presenting UA before the presentation
page is loaded. I'm objecting to mandating that, on the grounds described
above. Of course if we don't mandate it, then people would still be free to
implement it that way, but that would also be free to implement a UA with
persistent IndexedDB like on desktops/laptops and the latter would have
better UX in many cases (IMO).

...Mark



>
> Both web based OSs, and web based TVs are heavily under research. So
> trying to mandate any particular behavior here seems unlikely to
> actually result in multiple implementations. Unless we have multiple
> hardware vendors willing to commit to implement a particular behavior,
> we would effectively be just writing fiction.
>
> I do think that this is a super interesting field though. But I'd
> rather keep it out of the main spec for now. If we can find multiple
> hardware vendors that are willing to sign up and implement a fully
> specified web based TV platform, then I'd love to collaborate on a
> spec for that.
>
> / Jonas
>