Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of fil@adobe.com designates
 64.18.1.31 as permitted sender)
From: Filip Maj <fil@adobe.com>
To: "callback-dev@incubator.apache.org" <callback-dev@incubator.apache.org>
Date: Wed, 14 Mar 2012 11:59:26 -0700
Subject: Re: navigator.orientation API + tests
Thread-Topic: navigator.orientation API + tests
Thread-Index: Ac0CFJQsTCLjHEQHQmq4rvTuLhCTyw==
Message-ID: <CB863857.1EFE%fil@adobe.com>
In-Reply-To: 
 <CAKP6k2u6Q4k=dduGD7dCgjsTsBKtBENLBPiJJO+z=pKEYr-sqw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

We already have tests for localStorage + sessionStorage. Our docs also
have websql in them. For consistency, should add websql storage tests.

On 3/14/12 11:48 AM, "Jesse" <purplecabbage@gmail.com> wrote:

>I'm cool with removing the tests.
>Should we test for other polyfils? WebSQL? localStorage? console.log?
>
>Here is a good write up on some of the inconsistencies with orientation
>[1]
>And a test page [2]
>
>[1]
>http://www.matthewgifford.com/2011/12/22/a-misconception-about-window-orie
>ntation/
>
>[2]  http://www.matthewgifford.com/tests/orientation/
>
>On Wed, Mar 14, 2012 at 11:14 AM, Filip Maj <fil@adobe.com> wrote:
>
>> OK, if you guys think we should really keep it in iOS, that's fine. That
>> being said, we should REALLY either:
>>
>> - remove the orientation tests from mobile spec (or don't include them
>>in
>> the auto test runs) and let this be a magical iOS only API
>>
>> OR:
>>
>> - add support for this API to all other platforms, and document that it
>> exists and how to use it.
>>
>> On 3/14/12 11:08 AM, "Shazron" <shazron@gmail.com> wrote:
>>
>> >According to this, resize event might not be reliable on iOS to detect
>> >orientation change:
>> >
>>=20
>>http://stackoverflow.com/questions/1649086/detect-rotation-of-android-pho
>>n
>> >e-in-the-browser-with-javascript
>> >
>> >In my opinion if we chase a standard but it's not reliable - it's just
>> >going to frustrate users, especially if we take away a feature that is
>> >already working well.
>> >
>> >On Wed, Mar 14, 2012 at 10:55 AM, Filip Maj <fil@adobe.com> wrote:
>> >> My opinion is it should be a W3C spec for it be considered "default
>> >> browser behavior".
>> >>
>> >> The only "specification" for this that I can find is Apple's
>> >>documentation.
>> >>
>> >> On 3/14/12 10:45 AM, "Jesse" <purplecabbage@gmail.com> wrote:
>> >>
>> >>>WP7 supports the orientationchange event, and window.orientation
>>stores
>> >>>the
>> >>>current value.
>> >>>I believe this concept was started in early Mobile Safari on iOS and
>>has
>> >>>been cloned in the other WebKit devices.
>> >>>
>> >>>In my mind this is default expected browser behaviour and should be
>> >>>carried
>> >>>through to our implementation, although I cannot find a spec or list
>>of
>> >>>which mobile browsers support it.
>> >>>
>> >>>On Tue, Mar 13, 2012 at 1:07 PM, Filip Maj <fil@adobe.com> wrote:
>> >>>
>> >>>> Pretty sure iOS is the only platform with this implementation.
>> >>>>
>> >>>> On 3/13/12 12:40 PM, "Shazron" <shazron@gmail.com> wrote:
>> >>>>
>> >>>> >I just realize the resize event will only work for iOS if we throw
>> >>>>out
>> >>>> >the concept of there being two types of Landscape and Portrait
>> >>>> >(LandscapeLeft, LandscapeRight, Portrait and PortraitUpsideDown)
>> >>>>which
>> >>>> >exist with the current window.orientation. Are the two types of
>> >>>> >Landscape and Portrait only used in iOS, what about BB and
>>Android,
>> >>>>or
>> >>>> >WP7?
>> >>>> >
>> >>>> >On Tue, Mar 13, 2012 at 10:28 AM, Filip Maj <fil@adobe.com> wrote:
>> >>>> >> Certainly works on Android and at least on the Torch (BBs with
>>an
>> >>>> >> accelerometer)
>> >>>> >>
>> >>>> >> On 3/13/12 10:21 AM, "Shazron" <shazron@gmail.com> wrote:
>> >>>> >>
>> >>>> >>>Is that what Android / BB does and is reliable and tested?
>> >>>> >>>
>> >>>> >>>On Tue, Mar 13, 2012 at 9:15 AM, Filip Maj <fil@adobe.com>
>>wrote:
>> >>>> >>>> I don't think we need to jump on supporting the new
>> >>>> >>>> (DeviceOrientation/Motion) events in the cordova API right
>>away.
>> >>>> >>>>
>> >>>> >>>> As a first step I would simply remove the tests for
>> >>>> >>>>window.orientation.
>> >>>> >>>>
>> >>>> >>>> As for replacing it: you can attach to the "resize" event on
>> >>>>window,
>> >>>> >>>>and
>> >>>> >>>> compare the screen width vs. screen height to figure out what
>> >>>> >>>>orientation
>> >>>> >>>> the device is in.
>> >>>> >>>>
>> >>>> >>>> On 3/13/12 9:02 AM, "Shazron" <shazron@gmail.com> wrote:
>> >>>> >>>>
>> >>>> >>>>>If we go ahead with removing iOS < 4.2 support, the
>>backfilling
>> >>>>of
>> >>>> >>>>>support of the two events in JS can be removed:
>> >>>> >>>>>https://issues.apache.org/jira/browse/CB-93
>> >>>> >>>>>
>> >>>> >>>>>I'll let others chime in about removing window.orientation in
>>iOS
>> >>>> >>>>>before adding an issue in jira.
>> >>>> >>>>>
>> >>>> >>>>>If we remove it, here are my recommendations:
>> >>>> >>>>>   1) Remove iOS < 4.2 support in Cordova
>> >>>> >>>>>   2) Write docs regarding what replaces window.orientation,
>>and
>> >>>>how
>> >>>> >>>>>to use the new event(s) to detect simple orientation changes
>> >>>> >>>>>
>> >>>> >>>>>
>> >>>> >>>>>On Tue, Mar 13, 2012 at 8:40 AM, Shazron <shazron@gmail.com>
>> >>>>wrote:
>> >>>> >>>>>> The iOS window.orientation and orientationchange event items
>> >>>>(which
>> >>>> >>>>>> are not W3C, and has been in iOS since 1.1) was to support
>> >>>>these
>> >>>> >>>>>> features in a UIWebView which came for free in Mobile
>>Safari.
>> >>>> >>>>>>Apple's
>> >>>> >>>>>> description is here:
>> >>>> >>>>>>
>> >>>> >>>>>>
>> >>>>=20
>>https://developer.apple.com/library/ios/#DOCUMENTATION/AppleApplicati
>> >>>> >>>>>>on
>> >>>> >>>>>>s/
>> >>>>
>>=20
>>>>>>>>>>>>Reference/SafariWebContent/HandlingEvents/HandlingEvents.html#/
>>>>>>>>>>>>/a
>> >>>>>>>>>>pp
>> >>>>>>>>>>le
>> >>>> >>>>>>_r
>> >>>> >>>>>>ef
>> >>>> >>>>>>/doc/uid/TP40006511-SW16
>> >>>> >>>>>>
>> >>>> >>>>>> Apple already supports the DeviceMotionEvent and
>> >>>> >>>>>> DeviceOrientationEvents in iOS 4.2 (which we backfill
>>support
>> >>>>for
>> >>>> >>>>>> older iOS versions) and those are W3C drafts are I believe.
>> >>>> >>>>>>
>> >>>> >>>>>>
>> >>>>=20
>>http://www.mobilexweb.com/blog/safari-ios-accelerometer-websockets-ht
>> >>>> >>>>>>ml
>> >>>> >>>>>>5
>> >>>> >>>>>>
>> >>>> >>>>>> Also those two events are not exact replacements for
>> >>>> >>>>>> window.orientation - we would need to have to have
>>equivalents
>> >>>>/
>> >>>> >>>>>> educate users on how to map the event values to the
>>appropriate
>> >>>> >>>>>> window.orientation ones.
>> >>>> >>>>>>
>> >>>> >>>>>> Shaz
>> >>>> >>>>>>
>> >>>> >>>>>> On Tue, Mar 13, 2012 at 8:19 AM, Filip Maj <fil@adobe.com>
>> >>>>wrote:
>> >>>> >>>>>>> Hey all,
>> >>>> >>>>>>>
>> >>>> >>>>>>> In mobile-spec we have a series of tests checking an API
>> >>>>available
>> >>>> >>>>>>>at
>> >>>> >>>>>>>navigator.orientation [1]. From what I can tell / remember,
>> >>>>this
>> >>>>is
>> >>>> >>>>>>>something that we support as a legacy, as neither Android or
>> >>>> >>>>>>>BlackBerry
>> >>>> >>>>>>>have it but I believe there are leftovers in iOS (before
>> >>>>cordova-js
>> >>>> >>>>>>>integration) that still have this API.
>> >>>> >>>>>>>
>> >>>> >>>>>>> I do not think it is based on any W3C spec. The closest
>>thing
>> >>>>I
>> >>>> >>>>>>>could
>> >>>> >>>>>>>find is something the Geolocation Working Group are drafting
>> >>>>up,
>> >>>>an
>> >>>> >>>>>>>event called device orientation [2].
>> >>>> >>>>>>>
>> >>>> >>>>>>> My thinking is, remove this API completely. It is not part
>>of
>> >>>>our
>> >>>> >>>>>>>documentation and as far as I can tell only iOS supports it
>> >>>>right
>> >>>> >>>>>>>now.
>> >>>> >>>>>>>Instead, set new tasks to implement the W3C
>>deviceorientation
>> >>>>event
>> >>>> >>>>>>>(or
>> >>>> >>>>>>>perhaps come up with a simpler, synchronous API of our
>>own!).
>> >>>> >>>>>>>
>> >>>> >>>>>>> Thoughts?
>> >>>> >>>>
>> >>>> >>
>> >>>>
>> >>>>
>> >>
>>
>>