Re: User agent context for rendering the presentation (was: Re: Google/Mozilla Presentation API update)

DeviceOrientation events is definitely a very interesting question. I
would be ok with disabling those when the presentation page is running
"on the device" rather than "on the TV". Though for the 2 UA case I
think it would be fine to expose the orientation of the "TV". Consider
the case of displaying a presentation on a tablet rather than a TV for
example.

So maybe rather than disabling DeviceOrientation, we should define
that if possible, the events should reflect the orientation of the
device that the presentation stuff. If it's not possible to get
accurate information about that, then disable the API.

Though it would be good if things like the screen orientation API, and
APIs for getting window size, reflected the the orientation and size
of the window on the TV.

I also don't think it's generally true that we should disable all
device APIs. For example I think we should expose any game controllers
that are exposed to whatever device the page runs on. If it runs "on
the device" we expose controllers connected to the device, if it runs
"on the TV" we expose any controllers connected to the TV. Pages are
not going to come to depend on game controllers being connected
anyway.

/ Jonas

On Wed, Aug 20, 2014 at 11:47 AM, Bassbouss, Louay
<louay.bassbouss@fokus.fraunhofer.de> wrote:
> Hi Mark, all,
>
>
>
> Just returned from vacation and try to follow the discussion. What about
> Device APIs I think they should be also disabled in the presenting page.
> Otherwise the behavior of the application will be not the same between 1UA
> and 2UAs. For example if DeviceOrientation is used in the presenting page in
> the 1UA case it works  fine but not for 2 UAs.
>
>
>
> Best regards,
>
> Louay
>
> From: mark a. foltz [mailto:mfoltz@google.com]
> Sent: Mittwoch, 20. August 2014 19:27
> To: John Mellor
> Cc: Anton Vayvod; Francois Daoust; public-webscreens@w3.org; Jonas Sicking;
> Marco Chen; Wesley Johnston; Evelyn Hung
> Subject: Re: User agent context for rendering the presentation (was: Re:
> Google/Mozilla Presentation API update)
>
>
>
> Yes, that wording is better.  To be clear the presentation context should
> have access to all storage features, but the storage itself should behave as
> John describes.
>
>
>
>
>
> On Wed, Aug 20, 2014 at 6:15 AM, John Mellor <johnme@google.com> wrote:
>
> Drive-by: perhaps it would be better to say that presentation content has
> access to all these features as usual, but they always start off empty (and
> are emptied at the end of the session), as if the presentation content were
> launched in its own incognito window.
>
>
>
> On 20 August 2014 13:47, Anton Vayvod <avayvod@google.com> wrote:
>
> Hi Francois!
>
>
>
> The intent here wasn't to disable the feature for the presented page but to
> force the developers to only use the provided messaging channel between the
> presented and presenting pages. If the presented page relies on the
> presenting one to store something in the cache or IndexedDB for it, it can
> be implemented to work in the 1-UA case but not in the 2-UA case. The
> presented page should have access to these HTML features if the user agent
> running the presentation supports it.
>
>
>
> I think the wording for the above list should be clarified that there's "no
> access to cookies, local storage or IndexedDB instances in the browser
> context of the page that initiated the presentation".
>
> The same way as the same page loaded in a normal Chrome window and in an
> Incognito window will have no way of communicating with its instances
> through the use of cookies or storage APIs.
>
>
> Hope it helps,
>
> Anton.
>
>
>
> On Wed, Aug 20, 2014 at 12:09 PM, Francois Daoust <fd@w3.org> wrote:
>>
>> Hi Mark, Jonas, Anton, et al.,
>>
>> I have a question on the need to restrict the access to certain features
>> for presentation content.
>>
>> On 2014-08-14 02:05, mark a. foltz wrote:
>> [...]
>>>
>>> 4. User agent context for rendering the presentation.
>>>
>>>
>>> If we intend the same presentation content to be rendered either in the
>>> same user agent or a remote user agent, we need to carefully define the
>>> rendering context so that the application doesn't get different behavior
>>> according to whether it is rendered remotely or locally.  In particular
>>> the presentation rendering context must have:
>>>
>>>
>>> - No access to cookies, local storage or IndexedDB instances
>>>
>>> - No access to HTTP cache
>>>
>>> - No access to pre-existing SharedWorkers
>>>
>>> - Extensions are debatable - some may be required for e.g. VPN or
>>> firewalls to work correctly
>>
>>
>> I understand the need to have the presentation rendering context behave
>> similarly whether it runs locally or remotely, but I don't see the
>> implications in terms of restricting access to the features mentioned above.
>> For instance, I don't understand why having access to the local (or remote)
>> IndexedDB could pose a problem. A Web app that uses IndexedDB cannot assume
>> that the database exists, has the right version, or is not being used by
>> another tab that shares the same origin at the same time. How is running a
>> presentation context locally or remotely any different?
>>
>> Could you clarify why it matters? What issues are you trying to prevent?
>>
>> For example, in the AwesomeGame example that Jonas presented elsewhere in
>> the thread, it would make sense to me to have the "full game" run on the TV
>> set. If the game makes use of IndexedDB when it's available, then not being
>> able to use it on the TV set could noticeably affect performances or
>> available features.
>>
>> From a developer perspective, it would also mean that presentation apps
>> would not have the same powers as regular Web apps and would need to be
>> specifically tailored as presentation apps, which strikes me as odd. I would
>> rather expect to be able to take any Web app, even one that does not degrade
>> gracefully when e.g. IndexedDB is not available, complete it to run within a
>> presentation session, and be confident that it will work in any environment
>> that supports the features that the app is using. Granted, it's always good
>> practice to degrade gracefully (or rather to enhance progressively) but it's
>> not a reason to make that practice a requirement, especially for features
>> that developers rightfully start to take for granted in most browser
>> environments.
>>
>> Thanks,
>> Francois.
>
>
>
>

Received on Wednesday, 20 August 2014 21:44:07 UTC