Re: Screen orientation API proposal

[Dean Jackson]

On 22/01/2012, at 3:35 PM, Chris Jones wrote:

> ----- Original Message -----
>> From: "Paul Bakaus" <pba...@zynga.com>
>> To: "Dean Jackson" <di...@apple.com>, "Mounir Lamouri" <mou...@lamouri.fr>
>> Cc: mozilla-d...@lists.mozilla.org
>> Sent: Thursday, January 19, 2012 1:32:03 AM
>> Subject: Re: Screen orientation API proposal
>>
>
> For all the follow-on discussion, I think this is the last technical bone of contention:
>
>>> - After going around a while on this, we think the <meta> tag is an
>>> ok
>>> solution. We'd use a different name attribute. You'd just give a
>>> list of
>>> supported orientations.
>>>
>>> - For API, we propose that the meta tag be "live", in that if you
>>> want to
>>> restrict to portrait you set the value via JS and the orientation
>>> changes
>>> if necessary.
>>>
>
> Nested <iframe>s can go full screen. IIUC, this <meta> proposal would prevent those nested iframes from explicitly setting an orientation while full screen. That seems like an odd inconsistency. The full screen API has done all the legwork of spec'ing this out, so we've been proposing here to ride on those coattails for orientation locking.
>
> I don't really see much reason to prefer a <meta> tag over a DOM API. I see some reasons not to prefer it as relate to nested <iframe>s. And I do agree with Robin that a <meta> tag would be harder to spec. Not because of any particular abstract technical difficulty, just because it would require a lot more new work compared to drafting off of the full screen API (pun intended).

Just a small point: a <meta> tag is a DOM API. In fact, you're proposing a non-DOM API :)

One of the reasons we like this to be in markup is that we can process the file externally, and thus know in advance what the launch orientation of the page should be. For example, if the HTML is stored in the app cache. We'd prefer to not have to fire up a complete parsing and JS execution for that.

Dean

>
>>> - We originally proposed an event before orientation that could be
>>> cancelled, but now think this is a bad idea.
>
> Fwiw I 100% agree.
>
> Cheers,
> Chris

[Chris Jones]

window.screen is part of "DOM level 0", and so is a "DOM API", but I agree the terminology here is not particularly helpful. Not worth hanging up on.

> One of the reasons we like this to be in markup is that we can
> process the file externally, and thus know in advance what the
> launch orientation of the page should be. For example, if the HTML
> is stored in the app cache. We'd prefer to not have to fire up a
> complete parsing and JS execution for that.
>

We're proposing to have installable apps declare requested orientation in their manifests. See [1] for a WIP example. The syntax is JSON, so much easier to parse, and manifests themselves should be much smaller than the apps they describe. Manifests allow us to solve this problem and other similar ones quite easily.

Cheers,
Chris

[1] https://github.com/andreasgal/gaia/blob/master/apps/browser/manifest.webapp

[Paul Bakaus]

Am 24.01.12 07:58 schrieb "Chris Jones" unter <cjo...@mozilla.com>:

I agree with both of you. This should definitely be easily parsable, and I
agree with Chris that app manifests are a much much better idea (for all
kinds of reasons) than the meta tag madness. But this is probably content
for a much broader discussion.

[Chris Jones]

----- Original Message -----
> From: "Paul Bakaus" <pba...@zynga.com>
> To: "Chris Jones" <cjo...@mozilla.com>, "Dean Jackson" <di...@apple.com>
> Cc: mozilla-d...@lists.mozilla.org, "Mounir Lamouri" <mou...@lamouri.fr>
> Sent: Tuesday, January 24, 2012 12:46:54 AM
> Subject: Re: Screen orientation API proposal
>

> I agree with both of you. This should definitely be easily parsable,
> and I
> agree with Chris that app manifests are a much much better idea (for
> all
> kinds of reasons) than the meta tag madness. But this is probably
> content
> for a much broader discussion.
>

I think to move the screen orientation proposal forward, we should have at least part of that broader discussion.

Dean, has Apple been following the "web apps" efforts underway at Google and Mozilla? The manifest formats we're working on are designed to solve some of the problems you've almost certainly run into with iOS web apps. We very much want to ensure that iOS's use cases are covered too. Would you and/or your colleagues be interested in catching up through a higher-bandwidth medium?

Cheers,
Chris

[Dean Jackson]

On 25/01/2012, at 3:10 PM, Chris Jones wrote:

> ----- Original Message -----
>> From: "Paul Bakaus" <pba...@zynga.com>
>> To: "Chris Jones" <cjo...@mozilla.com>, "Dean Jackson" <di...@apple.com>
>> Cc: mozilla-d...@lists.mozilla.org, "Mounir Lamouri" <mou...@lamouri.fr>
>> Sent: Tuesday, January 24, 2012 12:46:54 AM
>> Subject: Re: Screen orientation API proposal
>>
>> I agree with both of you. This should definitely be easily parsable,
>> and I
>> agree with Chris that app manifests are a much much better idea (for
>> all
>> kinds of reasons) than the meta tag madness. But this is probably
>> content
>> for a much broader discussion.
>>
>
> I think to move the screen orientation proposal forward, we should have at least part of that broader discussion.
>
> Dean, has Apple been following the "web apps" efforts underway at Google and Mozilla?

I'm not sure exactly what you're referring to, sorry. Do you mean the W3C Web Apps WG?

> The manifest formats we're working on are designed to solve some of the problems you've almost certainly run into with iOS web apps. We very much want to ensure that iOS's use cases are covered too. Would you and/or your colleagues be interested in catching up through a higher-bandwidth medium?

Yes, I believe so - pointers appreciated. Any formal involvement by Apple (i.e. if it meant joining a standards group) is not my decision, but I'm definitely interested.

Dean

[Chris Jones]

----- Original Message -----
> From: "Mounir Lamouri" <mou...@lamouri.fr>
> To: dev-w...@lists.mozilla.org
> Cc: pba...@zynga.com, "Chris Pearce" <cpe...@mozilla.com>, "Boris Zbarsky" <bzba...@MIT.EDU>, di...@apple.com
> Sent: Wednesday, January 25, 2012 3:56:35 PM
> Subject: Re: Screen orientation API proposal
>

> It goes without saying but implementations of that API will be
> allowed
> to disallow locking following their own rules: an error event will be
> fired on the request object if locking isn't allowed per platform
> conventions.
>

For example, on a device with a system "orientation lock", if the system lock is engaged, an implementation of the DOM orientation-lock API is totally allowed to reject the lock request. And of course for any other UX reasons the impl has.

Cheers,
Chris

[Chris Jones]

----- Original Message -----
> From: "Mounir Lamouri" <mou...@lamouri.fr>
> To: dev-w...@lists.mozilla.org
> Cc: pba...@zynga.com, "Chris Pearce" <cpe...@mozilla.com>, "Boris Zbarsky" <bzba...@MIT.EDU>, di...@apple.com
> Sent: Wednesday, January 25, 2012 3:56:35 PM
> Subject: Re: Screen orientation API proposal
>

> interface ScreenLockRequest {
> readonly attribute DOMString readyState; // "processing" or
> "done"
> readonly attribute DOMError? error;
> attribute EventListener onsuccess;
> attribute EventListener onerror;
> attribute ScreenLock? result;
> }
>
> interface ScreenLock {
> void unlock();
> }
>

Is there any reason for these to be separate interfaces? I would find it more convenient to have unlock() on the request object, and just ignore the unlock() if the request failed or the lock had already been released.

A further point we discussed was that there are cases when the UA will need to drop *all* locks. One case might be when a "system orientation lock" is engaged. Other implementations are possible, of course. That would totally be up to the UA though, spec doesn't need to cover that.

Another case is most relevant to pages launched within browser chrome. For the reasons Dean brought up earlier, a browser might disallow orientation lock for in-chrome pages. But they would likely want to allow orientation lock for pages that go to full-screen (up to the UA still). However, when transitioning from full-screen to not-full-screen, the page transitions from an orientation-lock-allowed state to -disallowed state. On that transition, the UA might want to drop all orientation locks. This may or may not need to specified.

The spec *should* mention that any/all orientation locks can be dropped, at any time. I don't know if a notification of this is absolutely needed, but if we find a use case it would be pretty easy to fire an "onerror" callback to a lock object, or something else.

Cheers,
Chris

[Chris Jones]

----- Original Message -----
> From: "Dean Jackson" <di...@apple.com>
> To: "Chris Jones" <cjo...@mozilla.com>

> Cc: "Paul Bakaus" <pba...@zynga.com>, mozilla-d...@lists.mozilla.org, "Mounir Lamouri" <mou...@lamouri.fr>,
> "Jonas Sicking" <jo...@sicking.cc>, "Fabrice Desré" <fab...@mozilla.com>
> Sent: Wednesday, January 25, 2012 4:00:18 PM
> Subject: Re: Screen orientation API proposal
>
>

> On 25/01/2012, at 3:10 PM, Chris Jones wrote:
>

> > ----- Original Message -----
> >> From: "Paul Bakaus" <pba...@zynga.com>
> >> To: "Chris Jones" <cjo...@mozilla.com>, "Dean Jackson"
> >> <di...@apple.com>
> >> Cc: mozilla-d...@lists.mozilla.org, "Mounir Lamouri"
> >> <mou...@lamouri.fr>
> >> Sent: Tuesday, January 24, 2012 12:46:54 AM

> >> Subject: Re: Screen orientation API proposal
> >>

> >> I agree with both of you. This should definitely be easily
> >> parsable,
> >> and I
> >> agree with Chris that app manifests are a much much better idea
> >> (for
> >> all
> >> kinds of reasons) than the meta tag madness. But this is probably
> >> content
> >> for a much broader discussion.
> >>
> >
> > I think to move the screen orientation proposal forward, we should
> > have at least part of that broader discussion.
> >
> > Dean, has Apple been following the "web apps" efforts underway at
> > Google and Mozilla?
>
> I'm not sure exactly what you're referring to, sorry. Do you mean the
> W3C Web Apps WG?
>

I'm not sure if the Web Apps WG charter covers this work, TBH. One of the folks CC'd would know better than I.

> > The manifest formats we're working on are designed to solve some
> > of the problems you've almost certainly run into with iOS web
> > apps. We very much want to ensure that iOS's use cases are
> > covered too. Would you and/or your colleagues be interested in
> > catching up through a higher-bandwidth medium?
>
> Yes, I believe so - pointers appreciated. Any formal involvement by
> Apple (i.e. if it meant joining a standards group) is not my
> decision, but I'm definitely interested.
>

Sure, understood.

There are three efforts underway, mostly heading towards the same goals, and definitely moving towards some common standards

1. Google's "Installable Web Apps" for Chrome: http://code.google.com/chrome/apps/

2. Mozilla Labs' Open Web Apps project: https://developer.mozilla.org/en/Apps

3. A native implementation of installable web apps in Gecko, mostly for Boot2Gecko at the moment, eventually for Firefox: (There's no pretty overview page, but the latest work on installing apps themselves is ongoing in https://bugzilla.mozilla.org/show_bug.cgi?id=720415 . Some more discussion at https://etherpad.mozilla.org/apps-api-rev .)

The strategy and implementation of all three is somewhat different, but one important feature they share (relevant to the screen orientation API proposal here) is an "app manifest". In a nutshell, an app manifest is a separate JSON file that aggregates what boils down to a superset of the "apple-mobile-web-app-*" <meta> properties. Within a page, it will likely be referred to by something like <link rel="app-manifest" href="foo.manifest">. A page that has a manifest is an "installable web app". UAs can show special UI for installable apps browsed to in normal browser chrome.

There are several motivations for a separate manifest file. (If I miss some, folks on CC please correct me.)
- As I mentioned before, manifests are much smaller than the apps they refer to. This is important for "web app markets". A large collection of web apps can be enumerated through a small amount of manifest data. And when installing an app, the same link to the manifest can be passed to the engine's install() API. I.e. the manifest serves as a common interchange format.
- Similarly, UAs that don't understand manifest files can save on bandwidth by just ignoring the <link>. Harder with <meta>. The <link> can also be fetched on demand.
- More easily extensible format (JSON). <meta> is equivalently extensible, but at considerable syntactic overhead. Better author ergonomics, likely easier spec work.
- Manifest is read-only. It's not clear what should happen if an installed web app changes its <meta> tags after being installed, while it's running.

It's similarly easy for authors to use manifests and <meta> in a backwards and forwards compatible way. <link rel="app-manifest"> will be ignored in older UAs, and manifest-compatible UAs can ignore the <meta> tags.

Of course, like the three groups above, I'm sure Apple will have a distinct, fourth set of strategic goals. But it seems to me that so many use cases are common that it behooves all of us to find a common standard for application metadata.

Let us know how we can follow up on this.

Cheers,
Chris

[Mounir Lamouri]

On 01/26/2012 08:30 AM, Chris Jones wrote:
> ----- Original Message -----

>> From: "Mounir Lamouri" <mou...@lamouri.fr>
>> To: dev-w...@lists.mozilla.org
>> Cc: pba...@zynga.com, "Chris Pearce" <cpe...@mozilla.com>, "Boris Zbarsky" <bzba...@MIT.EDU>, di...@apple.com

>> Sent: Wednesday, January 25, 2012 3:56:35 PM
>> Subject: Re: Screen orientation API proposal
>>

>> interface ScreenLockRequest {
>> readonly attribute DOMString readyState; // "processing" or
>> "done"
>> readonly attribute DOMError? error;
>> attribute EventListener onsuccess;
>> attribute EventListener onerror;
>> attribute ScreenLock? result;
>> }
>>
>> interface ScreenLock {
>> void unlock();
>> }
>>
>
> Is there any reason for these to be separate interfaces? I would find it more convenient to have unlock() on the request object, and just ignore the unlock() if the request failed or the lock had already been released.

That would break the purpose of Request objects and result attribute. In
addition, if it seems not too bad for one function, that might go crazy
if we end up adding attributes.
I would prefer to keep the two interfaces for sanity.

> Another case is most relevant to pages launched within browser chrome. For the reasons Dean brought up earlier, a browser might disallow orientation lock for in-chrome pages. But they would likely want to allow orientation lock for pages that go to full-screen (up to the UA still). However, when transitioning from full-screen to not-full-screen, the page transitions from an orientation-lock-allowed state to -disallowed state. On that transition, the UA might want to drop all orientation locks. This may or may not need to specified.
>
> The spec *should* mention that any/all orientation locks can be dropped, at any time. I don't know if a notification of this is absolutely needed, but if we find a use case it would be pretty easy to fire an "onerror" callback to a lock object, or something else.

Sending an error event to the Request object wouldn't be doable. Request
objects receive one event (success or error) and at that point, their
state shouldn't change. At least, not being reverted.
I think we might need something to let the author know the lock has been
removed mostly because removing the lock is going to be UA specific
neither specs nor authors can predict when UA are going to do that.

I think we could send an unlock event to the ScreenLock object when the
is actually unlocked. That would apply for calling unlock() manually or
when the UA wants to unlock. That way, apps will be also able to know
when the unlock they did request actually happens (which isn't really
doable right now). How does that sound?

--
Mounir

[Chris Jones]

What's the purpose of the result attribute? I think you're begging the question.

> In
> addition, if it seems not too bad for one function, that might go
> crazy
> if we end up adding attributes.
> I would prefer to keep the two interfaces for sanity.
>

When discussing examples of this pattern with jlebar, I argued that it's not more code than global lock()/unlock(). With these separate interfaces, it is.

window.screen.lockOrientation("portrait");
//...
window.screen.unlockOrientation();

vs.

var lock;
var req = window.screen.requestOrientationLock("portrait");
req.onsuccess = function () { lock = req.result; };
//...
if (lock)
lock.unlock();

So I withdraw my argument. Sorry jlebar!

I'm not seeing concrete reasons for separating the two interfaces. Would like to see them.

> > Another case is most relevant to pages launched within browser
> > chrome. For the reasons Dean brought up earlier, a browser might
> > disallow orientation lock for in-chrome pages. But they would
> > likely want to allow orientation lock for pages that go to
> > full-screen (up to the UA still). However, when transitioning
> > from full-screen to not-full-screen, the page transitions from an
> > orientation-lock-allowed state to -disallowed state. On that
> > transition, the UA might want to drop all orientation locks. This
> > may or may not need to specified.
> >
> > The spec *should* mention that any/all orientation locks can be
> > dropped, at any time. I don't know if a notification of this is
> > absolutely needed, but if we find a use case it would be pretty
> > easy to fire an "onerror" callback to a lock object, or something
> > else.
>
> Sending an error event to the Request object wouldn't be doable.
> Request
> objects receive one event (success or error) and at that point, their
> state shouldn't change. At least, not being reverted.
> I think we might need something to let the author know the lock has
> been
> removed mostly because removing the lock is going to be UA specific
> neither specs nor authors can predict when UA are going to do that.
>

I don't have a use case in mind yet for authors reacting to revoked locks. What would they do? But your proposal sounds OK, whichever interface it goes on. We can also add that in a later spec.

Cheers,
Chris

[Vivien]

On 26/01/2012 00:56, Mounir Lamouri wrote:
> Hi,
>
> After discussing this API with Chris, I believe we might have find a
> consensus. If no-one comes with strong reasons to block this, I will
> implement the API and try to have the proposal move to a WG or a TF.
>
> Regarding UX, we think locking should be allowed when the content is
> in fullscreen or more generally when the webapp use the entire screen
> (for example, any webapp installed on a phone/tablet). We are going to
> punt to the UX team to decide if and how we should allow regular
> content to lock the screen.

In Gaia the homescreen, which is also a webapp, contains all the other
window. Webapps are not fullscreen but contained into an iframe that is
smaller than the height of the screen. So except the homescreen, nothing
is fullscreen. (There will be an API to make an app fullscreen but
that's an other question).


Also what if a webapps lock the screen in portrait and then the virtual
keyboard pop-up (the application window is resized). Does it means the
lock will be cancelled?

[Chris Jones]

----- Original Message -----
> From: "Vivien" <2...@vingtetun.org>
> To: dev-w...@lists.mozilla.org
> Sent: Friday, January 27, 2012 9:46:12 AM
> Subject: Re: Screen orientation API proposal
>

> On 26/01/2012 00:56, Mounir Lamouri wrote:
> > Hi,
> >
> > After discussing this API with Chris, I believe we might have find
> > a
> > consensus. If no-one comes with strong reasons to block this, I
> > will
> > implement the API and try to have the proposal move to a WG or a
> > TF.
> >
> > Regarding UX, we think locking should be allowed when the content
> > is
> > in fullscreen or more generally when the webapp use the entire
> > screen
> > (for example, any webapp installed on a phone/tablet). We are going
> > to
> > punt to the UX team to decide if and how we should allow regular
> > content to lock the screen.
>
> In Gaia the homescreen, which is also a webapp, contains all the
> other
> window. Webapps are not fullscreen but contained into an iframe that
> is
> smaller than the height of the screen. So except the homescreen,
> nothing
> is fullscreen. (There will be an API to make an app fullscreen but
> that's an other question).
>

Mounir meant, "all the available screen space". As opposed to say, desktop Windows 7, where I can have 10 windows visible on the same screen. Any one of those windows trying to lock orientation probably doesn't make sense. Similarly, I can "maximize" a window in Windows 7, and it might make sense to allow maximized windows to lock orientation. *All* application windows are "maximized" in gaia and most other phone OSes.

>
> Also what if a webapps lock the screen in portrait and then the
> virtual
> keyboard pop-up (the application window is resized). Does it means
> the
> lock will be cancelled?
>

No, why would it? The IME is part of the app, for all intents and purposes.

Cheers,
Chris