485943 - (DeviceOrientation) Device Orientation Support

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Doug Turner (:dougt)]

I would like something that allows me to monitor changes in the orientation of the browser.  For example, if the phone or laptop is tilted, i would like to reflect those changes for script.

For example, something similar to geolocation support:


navigator.orientation.watchOrientation(draw);

function draw(o) {
  // o.x, o.y, o.z  
}

o in function draw is a vector in three dimensional space in meter / (seconds^2).

Comment 1

[Doug Turner (:dougt)]

Attachment: patch v.1

This is a first cut at adding device orientation support to the browser.  The only backend is provided on HTC devices (Touch Pro, Diamond, HD, etc).

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

The patch missed the interfaces.

Comment 3

[Doug Turner (:dougt)]

Attachment: patch v.1 w/ interfaces

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

So I think using DOM Events here would be easier for web developers.
window object could have .orientation property, which have .x, .z, .y and
orientationChanged (or MozOrientationChanged) event could be dispatched to window when needed.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Or alternatively the orientationChanged event could contain
.x/.y/.z fields.
That might be actually even better. No need to add any new object to global
scope.

The event interface could be something like this:
interface nsIDOMOrientationEvent : nsIDOMEvent
{
  void                      initEvent(in DOMString eventTypeArg,
                                      in boolean canBubbleArg,
                                      in boolean cancelableArg,
                                      in double x;
                                      in double y;
                                      in double z);
  readonly attribute double x;
  readonly attribute double y;
  readonly attribute double z;
};

Comment 6

[Alex Vincent [:WeirdAl]]

Peanut gallery observation:  should this be based on an ifdef or mozconfig flag?  Stock Firefox, Thunderbird, XULRunner apps (most apps, for that matter) don't have a desktop equivalent.  My point is this is unnecessary for most desktop applications.

It's not entirely clear in the patch this would apply only for mobile applications.

Comment 7

[Doug Turner (:dougt)]

Alex, off topic, but an important point:

the goal here is that there isn't any difference between the stuff we expose in the DOM on mobile and the stuff we expose in the DOM on desktop.  Having separate APIs between platforms and between applications yields nothing but fragmentation and developer discontent. One web.

Furthermore, who knows what XR apps will use this?  Why would you artificially restrict this API because you can not foresee how developer might use it down the road?

if you care to discuss this further, lets do it in the mailing list because not as many people will read this bug as will read the lists.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

I wonder how to expose the initial orientation with events only approach.
Perhaps comment #4 is better after all.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I agree this should be a DOM event, not a callback.

Comment 10

[Mark Finkle (:mfinkle) (use needinfo?)]

I like the direction of comment #5

Comment 11

[Doug Turner (:dougt)]

@smaug, @roc, could you express why a DOM event over a callback.  I am just
curious and have no real reason to like one over the other.

@mfinkle i am not orthogonal to that direction.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

DOM events are simply how the Web does things like this. We also have a lot of infrastructure and knowledge built up about how to handle icky situations like you have several callbacks and the first one to fire closes the window.

Comment 13

[Justin Dolske [:Dolske]]

Random comments:

* Is "orientation" the right term to use? It's really just 3-axis accelerations, right? If I'm dropping my device (free-fall) or in the process of throwing it at your head, the true orientation isn't really going to be indicated. Potential name conflict with an API for a magnetic compass? [I'm bouncing back and forth between saying "close enough" and "important if subtle distinction."]

* There definitely is desktop applicability... MacBooks have an accelerometer that can provide this data. http://osxbook.com/book/bonus/chapter10/ams/

* String theory predicts 10 or more dimensions, so this API should be extensible for the next generation of sub-atomic mobile devices. [:-)]

(In reply to comment #11)

> @mfinkle i am not orthogonal to that direction.

Are puns normal to an device orientation discussion?

Comment 14

[Fabrice Desré]

This kind of stuff should be done the DCCI way instead of using custom interfaces : http://www.w3.org/TR/DPF/

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #14)
> This kind of stuff should be done the DCCI way instead of using custom
> interfaces : http://www.w3.org/TR/DPF/
DCCI doesn't specify any useful interfaces either. It is "just" a framework.
For orientation we can and should have something simple.

(In reply to comment #10)
> I like the direction of comment #5
That doesn't solve the "initial orientation" problem.
So I prefer #4

Comment 16

[Fabrice Desré]

(In reply to comment #15)
> (In reply to comment #14)
> > This kind of stuff should be done the DCCI way instead of using custom
> > interfaces : http://www.w3.org/TR/DPF/
> DCCI doesn't specify any useful interfaces either. It is "just" a framework.
> For orientation we can and should have something simple.

 That's true that this is a framework and that you'll have to define your own properties. Note that you could use custom properties and propose them to be added to the DCCI ontology (http://www.w3.org/TR/dcontology/), pretty much in the same way CSS -moz-* properties sometimes end up in CSS specs.

Comment 17

[Doug Turner (:dougt)]

@fabrice, I am all for simplicity for the web developer (not so much the spec developer).  Could you show a sample of orientation using DCCI similar to what I did in: http://people.mozilla.org/~dougt/ball.html

@dolske, acceleration might be better.  I didn't think that the "Sudden Motion Sensor" was a accelerometer.  If it is, woot!  I can test this on my MBP.  Lastly, string theory doesn't have tests (there is a testcase-wanted bug somewhere) and, therefore, 4 dimensions is all i want.

Comment 18

[Keith Rosenblatt]

(In reply to comment #17)
> @fabrice, I am all for simplicity for the web developer (not so much the spec
> developer).  Could you show a sample of orientation using DCCI similar to what
> I did in: http://people.mozilla.org/~dougt/ball.html

Following are modifications to your example, working on the assumption that there's a DCCI orientation property that matches the semantics of your own (though, having a value that's a string of comma-delimited x and y.)  

Forgive any errors.  I didn't write such an orientation property to test.

===

var ORIENTATION_NAMESPACEURI = "*"  // actual namespace would be known
var ORIENTATION_PROPERTYNAME = "orientation"

function init() {

  // start watching orientation changes.

  try {
    var nodelist = dcci.searchProperty(ORIENTATION_NAMESPACEURI, ORIENTATION_PROPERTYNAME, null, true);
    var orientation = nodelist.item(0);

    orientation.addEventListener("DCCI-prop-change", draw, true);
  } catch (ex) {
    // here is where you would handle errors gracefully
  }
}

function draw(e) {
  var ctx = document.getElementById("canvas").getContext("2d");
  var vals = e.target.value.split(",");
  var dx = vals[0];
  var dy = vals[1];

  // clear the last place the ball was
  ctx.clearRect(x-r-1 , y-r-1, x+r+1, y+r+1);

  // prevent the ball from rolling outside on the X-axis
  if ( (x + dx) < (WIDTH - r) && (x + dx) > r)
    x += dx;

  // prevent the ball from rolling outside on the Y-axis
  if ((y + dy) < (HEIGHT - r) && (y + dy) > r)
    y += dy;


  // draw the ball
  ctx.beginPath();
  ctx.arc(x, y, r, 0, Math.PI*2, true);
  ctx.closePath();
  ctx.fill();

}

Comment 19

[Doug Turner (:dougt)]

seems like alot of overhead.  I think I would rather just do something like:

addEventListener("orientation", draw, true);

But, i guess this is the main argument against dcci isn't it?

Comment 20

[kantha kanchiraju]

Attachment: patch v2 with Omnia Support

This Patch adds support for Orientation on Samsung Omnia. 
This also fixes a UUID clash between nsIDOMOrientationOptions and nsIDOMGeoPositionOptions.

For the Orientation to work on Samsung Omnia smi_wm_sdk_redist_1_0_0.cab must be installed on the device.

Comment 21

[Doug Turner (:dougt)]

Attachment: patch v.1 (events)

work in progress.

When you have content like:

   window.addEventListener("orientation", orientationChanged, false);

to the nsGlobalWindow will see it and a new method called SetHasOrientationEventListener will be invoked.


I would imagine instead of doing a printf, we could call some service, and tell this service about the window asking for the notifications.  The only think we need to figure out is how to correctly remove such a registered window from our service.  (maybe in the destructor of nsGlobalWindow?)

Comment 22

[Doug Turner (:dougt)]

Attachment: patch v.2 (events)

This also has a cocoa impl. that works on most macbooks.

Comment 23

[Doug Turner (:dougt)]

the cocoa implementation is busted. :-)  I think I am reading too much from the device.  I will investigate and post a new patch.  Please consider the rest of the patch ready for review.

Comment 24

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 390967 [details] [diff] [review]
patch v.2 (events)

>diff --git a/content/base/src/nsContentUtils.cpp b/content/base/src/nsContentUtils.cpp
>--- a/content/base/src/nsContentUtils.cpp
>+++ b/content/base/src/nsContentUtils.cpp
>@@ -496,17 +496,18 @@ nsContentUtils::InitializeEventTable() {
>     { &nsGkAtoms::onMozSwipeGesture,             { NS_SIMPLE_GESTURE_SWIPE, EventNameType_None } },
>+// orientation support
>+GK_ATOM(onOrientation, "onorientation")
>+

This should be GK_ATOM(onMozOrientation, "onMozOrientation")


>+#ifndef nsDOMOrientationEvent_h__
>+#define nsDOMOrientationEvent_h__
>+
>+#include "nsIDOMOrientationEvent.h"
>+#include "nsDOMEvent.h"
>+#include "nsIURI.h"
Do you really need nsIURI.h here?


>+protected:
>+  double mX, mY, mZ;
You should initialize these to 0 in the ctor.

>+[scriptable, uuid(1618546a-c176-40a2-9086-2d973acceeb1)]
>+interface nsIDOMOrientationEvent : nsIDOMEvent
>+{
>+  void                      initOrientationEvent(in DOMString eventTypeArg,
>+                                                 in boolean canBubbleArg,
>+                                                 in boolean cancelableArg,
>+                                                 in double x,
>+                                                 in double y,
>+                                                 in double z);
>+  readonly attribute double x;
>+  readonly attribute double y;
>+  readonly attribute double z;
Please add some documentation.


>+++ b/widget/public/nsGUIEvent.h
>@@ -83,17 +83,16 @@ class nsHashKey;
> #define NS_COMPOSITION_EVENT              14
> #define NS_MOUSE_SCROLL_EVENT             16
> #define NS_SCROLLPORT_EVENT               18
> #define NS_MUTATION_EVENT                 19 // |nsMutationEvent| in content
> #define NS_ACCESSIBLE_EVENT               20
> #define NS_FORM_EVENT                     21
> #define NS_POPUP_EVENT                    23
> #define NS_COMMAND_EVENT                  24
>-
The extra line here is sort of for reason.

>+        oe->InitOrientationEvent(NS_LITERAL_STRING("orientation"),
"MozOrientation"

>+protected:
>+
>+  virtual void startup()  = 0;
>+  virtual void shutdown() = 0;
Why startup/shutdown and not Startup/Shutdown?

Will re-review once OSX part is working.

Comment 25

[Doug Turner (:dougt)]

Attachment: patch v.3 (events)

addressed your concerns.  I think we can add more docs to the interface when we know more about how other hw's work and adjust as we go.

the mac problem was sorta weird. we have to read exactly 40 bytes out of the buffer or the call to IOConnectMethodStructureIStructureO fails. comment added.

Comment 26

[Olli Pettay [:smaug][[e-mail]]]

Do you have any testcases for this? (even just manual tests)

Comment 27

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 393328 [details] [diff] [review]
patch v.3 (events)

>+#ifndef nsDOMOrientationEvent_h__
>+#define nsDOMOrientationEvent_h__
>+
>+#include "nsIDOMOrientationEvent.h"
>+#include "nsDOMEvent.h"
>+#include "nsIURI.h"
Why you need nsIURI.h?

>+
>+  /**
>+   * Tell window that there is an observer for orientation changes
>+   */
>+  virtual void SetHasOrientationEventListener() = 0;
"Tell the window"?

>+++ b/dom/interfaces/events/nsIDOMOrientationEvent.idl
>@@ -0,0 +1,59 @@
>+/* ***** BEGIN LICENSE BLOCK *****
>+ * Version: MPL 1.1/GPL 2.0/LGPL 2.1
>+ *
>+ * The contents of this file are subject to the Mozilla Public License Version
>+ * 1.1 (the "License"); you may not use this file except in compliance with
>+ * the License. You may obtain a copy of the License at
>+ * http://www.mozilla.org/MPL/
>+ *
>+ * Software distributed under the License is distributed on an "AS IS" basis,
>+ * WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
>+ * for the specific language governing rights and limitations under the
>+ * License.
>+ *
>+ * The Original Code is mozilla.org code.
>+ *
>+ * The Initial Developer of the Original Code is
>+ * Doug Turner <[e-mail]>
>+ * Portions created by the Initial Developer are Copyright (C) 2009
>+ * the Initial Developer. All Rights Reserved.
Is Initial Developer you or MoFo or MoCo?

>+[scriptable, uuid(4B04E228-0B33-43FC-971F-AF60CEDB1C21)]
>+interface nsIAccelerometer : nsISupports
>+{
>+  void addListener(in nsIAccelerationListener aListener);
>+  void removeListener(in nsIAccelerationListener aListener);
>+
>+  void addWindowListener(in nsIDOMWindow aWindow);
>+  void removeWindowListener(in nsIDOMWindow aWindow);
Why there 2 different listener types?
Couldn't nsGlobalWindow implement nsIAccelerationListener?
>diff --git a/widget/src/cocoa/nsAccelerometerX.h b/widget/src/cocoa/nsAccelerometerX.h
I think josh or mstange should review this.

>+  if (mUpdateTimer)
>+    mUpdateTimer->InitWithFuncCallback(UpdateHandler,
>+                                       this,
>+                                       200, /* todo -- we want to pref this?  or maybe add this to some API? */
>+                                       nsITimer::TYPE_REPEATING_SLACK);
Is it always guaranteed that the timer is canceled before 'this' is deleted?


>+void 
>+nsAccelerometer::AccelerationChanged(double x, double y, double z)
>+{
>+  for (PRUint32 i = mListeners.Count(); i > 0 ; ) {
>+    --i;
>+    nsRefPtr<nsIAcceleration> a = new nsAcceleration(x, y, z);
>+    mListeners[i]->OnAccelerationChange(a);
>+  }
>+
>+  for (PRUint32 i = mWindowListeners.Count(); i > 0 ; ) {
>+    --i;
>+
>+    nsCOMPtr<nsIDOMDocument> domdoc;
>+    mWindowListeners[i]->GetDocument(getter_AddRefs(domdoc));
>+
>+    nsCOMPtr<nsIDOMDocumentEvent> docevent(do_QueryInterface(domdoc));
>+    nsCOMPtr<nsIDOMEvent> event;
>+
>+    PRBool defaultActionEnabled = PR_TRUE;
>+
>+    if (docevent) {
>+      docevent->CreateEvent(NS_LITERAL_STRING("orientation"), getter_AddRefs(event));
>+
>+      nsCOMPtr<nsIDOMOrientationEvent> oe = do_QueryInterface(event);
>+
>+      if (event) {
>+        oe->InitOrientationEvent(NS_LITERAL_STRING("MozOrientation"),
>+                                 PR_TRUE,
>+                                 PR_FALSE,
>+                                 x,
>+                                 y,
>+                                 z);
>+
>+        nsCOMPtr<nsIPrivateDOMEvent> privateEvent = do_QueryInterface(event);
>+        if (privateEvent)
>+          privateEvent->SetTrusted(PR_TRUE);
>+        
>+        nsCOMPtr<nsIDOMEventTarget> target(do_QueryInterface(mWindowListeners[i]));
>+        target->DispatchEvent(event, &defaultActionEnabled);
>+      }
>+    }
>+  }
The event dispatch would move to nsGlobalWindow, if nsGlobalWindow was a normal
acceleration listener.

r-, mainly because of two kinds off acceleration listeners. I you can convince me that those are really needed, then r+ :)

Comment 28

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 393328 [details] [diff] [review]
patch v.3 (events)

>diff --git a/content/base/src/nsContentUtils.cpp b/content/base/src/nsContentUtils.cpp
>--- a/content/base/src/nsContentUtils.cpp
>+++ b/content/base/src/nsContentUtils.cpp
>@@ -496,17 +496,18 @@ nsContentUtils::InitializeEventTable() {
>     { &nsGkAtoms::onMozSwipeGesture,             { NS_SIMPLE_GESTURE_SWIPE, EventNameType_None } },
>     { &nsGkAtoms::onMozMagnifyGestureStart,      { NS_SIMPLE_GESTURE_MAGNIFY_START, EventNameType_None } },
>     { &nsGkAtoms::onMozMagnifyGestureUpdate,     { NS_SIMPLE_GESTURE_MAGNIFY_UPDATE, EventNameType_None } },
>     { &nsGkAtoms::onMozMagnifyGesture,           { NS_SIMPLE_GESTURE_MAGNIFY, EventNameType_None } },
>     { &nsGkAtoms::onMozRotateGestureStart,       { NS_SIMPLE_GESTURE_ROTATE_START, EventNameType_None } },
>     { &nsGkAtoms::onMozRotateGestureUpdate,      { NS_SIMPLE_GESTURE_ROTATE_UPDATE, EventNameType_None } },
>     { &nsGkAtoms::onMozRotateGesture,            { NS_SIMPLE_GESTURE_ROTATE, EventNameType_None } },
>     { &nsGkAtoms::onMozTapGesture,               { NS_SIMPLE_GESTURE_TAP, EventNameType_None } },
>-    { &nsGkAtoms::onMozPressTapGesture,          { NS_SIMPLE_GESTURE_PRESSTAP, EventNameType_None } }
>+    { &nsGkAtoms::onMozPressTapGesture,          { NS_SIMPLE_GESTURE_PRESSTAP, EventNameType_None } },
>+    { &nsGkAtoms::onMozOrientation,              { NS_ORIENTATION_EVENT, EventNameType_None }},
Do you actually need this and NS_ORIENTATION_EVENT in nsGUIEvent.h?
You could just check that aTypeAtom == nsGkAtoms::onMozOrientation in nsEventListenerManager.

Comment 29

[Olli Pettay [:smaug][[e-mail]]]

Does the patch fire MozOrientation every 200ms, even if nothing has changed?

Comment 30

[Olli Pettay [:smaug][[e-mail]]]

Might make sense to fire the event only if something changes, or if there are
new acceleration listeners which haven't been notified.

Comment 31

[Doug Turner (:dougt)]

olli, thanks for the reviews.  I could make global window derive from this new interface.  however it is currently defined in widget and that would be a new depend.  Do suggest a better place for nsIAccelerometer.idl?

Comment 32

[Doug Turner (:dougt)]

jst ^

Comment 33

[Johnny Stenback (:jst)]

Looking at the interface it seems like making our window objects inherit from nsIAccelerometer would add these methods to all windows:

  void addListener(in nsIAccelerationListener aListener);
  void removeListener(in nsIAccelerationListener aListener);
  void addWindowListener(in nsIDOMWindow aWindow);
  void removeWindowListener(in nsIDOMWindow aWindow);

and adding that to the global scope of every webpage doesn't seem like a good idea to me. What does WebKit do, or does it use this interface or anything like it yet?

Comment 34

[Doug Turner (:dougt)]

I am not familiar with webkit's implementation of this. However, the point is that we do not want to add any of the above methods to content in any way.

Basically, i think what olli was asking for was that the nsGlobalWindow would implement nsIAccelerationListener so that it could be notified of orientation changes, then pass these changes as events to the associated document.

Comment 35

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #34)
> Basically, i think what olli was asking for was that the nsGlobalWindow would
> implement nsIAccelerationListener so that it could be notified of orientation
> changes, then pass these changes as events to the associated document.
Right. That would make nsIAccelerometer interface simpler.

Comment 36

[Doug Turner (:dougt)]

just to be clear -- that should not expose anything to web content. ;-)

Comment 37

[Olli Pettay [:smaug][[e-mail]]]

Right. The only thing we expose to web content is possibility to add event listener for MozOrientation.

Comment 38

[Johnny Stenback (:jst)]

Ok.

There's still a risk in making nsGlobalWindow implement nsIAccelerometer since if it does and anyone QI's a window object to nsIAccelerometer from js, then XPConnect will from then on expose the methods in nsIAccelerometer on the window object no matter who's looking. IOW, if a chrome extension QI's a content window to nsIAccelerometer then script in that content window will from then on see the methods in that interface, and that's generally not desirable.

So in the end, I'd avoid it if possible.

Comment 39

[Olli Pettay [:smaug][[e-mail]]]

jst, you mean nsIAccelerationListener.
The only thing that interface exposes is onAccelerationChange, and
calling that would lead to dispatch MozOrientation, which can be dispatched
anyway.

Comment 40

[Olli Pettay [:smaug][[e-mail]]]

There is also the option to make interfaces non-scriptable.
I'm not sure when chrome would use the service and when events.

Comment 41

[Doug Turner (:dougt)]

i think you would want to keep this interface scriptable so that it can be used by addons/extensions/xulapps.  where should this interface live?

Comment 42

[Olli Pettay [:smaug][[e-mail]]]

But extensions etc can always use MozOrientation event.
It could be even optimized so that when the last event listener for MozOrientation
is removed from the window, the window is removed from accelerometer.

So what is the use case for scriptable interfaces?

Comment 43

[Olli Pettay [:smaug][[e-mail]]]

And if there is no real use case for scriptable nsIAccelerationListener, 
I think having void add/removeWindowListener(in nsIDOMWindow aWindow);
should be ok. 
We don't want any extra interfaces if the same can be done easily in some
other way, IMHO.

Comment 44

[Doug Turner (:dougt)]

from c++, and without a document handy, it is alot easier to use the interface.

Comment 45

[Johnny Stenback (:jst)]

Ok, yeah, nsIAccelerationListener is definitely less intrusive as far as global namespace pollution goes, but if the interface was non-scriptable this would be a non issue... Ease of use from binary extensions is not very high on my list of concerns here :)

Comment 46

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #44)
> from c++, and without a document handy, it is alot easier to use the interface.

That is not a "use case" ;)

But if you really think the nsIAccelerometer is good as it is now,
I can accept that. Please ask some josh, mstange or someone to review the OSX
part, and I could review the final patch.

Comment 47

[Doug Turner (:dougt)]

Attachment: patch v.4 (events w/o cocoa impl.)

olli, same as before but without the cocoa implementation.  I will post a follow up patch that josh or another machead-widget-person can review.

Also i fixed most of your concerns.  I do not think i can compare the aType directly with the nsGkAtoms::onMozOrientation (ISO C++ forbids comparison between pointer and integer).

As for tests, we can add Litmus in FF for the platforms that have the required hw.  I could also simulate posting onMozOrientation events, but am not sure if that is really needed since if that doesn't work, I am certain that other things will probably not work (the event dispatching stuff is pretty straight forward).   What do you think -- is it a good idea to just create a dummy onMozOrientation event, and see if it is received in a document?

Comment 48

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #47)
> Also i fixed most of your concerns.  I do not think i can compare the aType
> directly with the nsGkAtoms::onMozOrientation (ISO C++ forbids comparison
> between pointer and integer).
I didn't say 'aType', but 'aTypeAtom' ;)

Well at least post some tests here so that someone can verify easily that
the feature works. (Well, perhaps verifying after the OSX implementation is
committed.)

Comment 49

[Doug Turner (:dougt)]

olli, there is a test case in the url field of the bug that works.  I can switch to aTypeAtom.  please let me know of any other changes you think i should make.

Comment 50

[Olli Pettay [:smaug][[e-mail]]]

Could you please attach the testcase to this bug. Safer place and all...

Comment 51

[Doug Turner (:dougt)]

Attachment: test case

Comment 52

[Doug Turner (:dougt)]

Attachment: patch v.1 (cocoa widget implementation)

Comment 53

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 393769 [details] [diff] [review]
patch v.4 (events w/o cocoa impl.)

With the aTypeAtom thing (if that works).

Comment 54

[Josh Aas]

Comment on attachment 394044 [details] [diff] [review]
patch v.1 (cocoa widget implementation)

+#include <stdio.h>
+#include <stdint.h>
+#include <stdlib.h>

Why is this stuff necessary in the header?

+  kern_return_t result = IOConnectMethodStructureIStructureO(self->mSmsConnection,

Please prefix all Mac OS X calls with "::" like we do elsewhere in mac widget code. So "::IOConnectMethodStructureIStructureO". This needs to be fixed in a few places in the patch.

+  if (result != kIOReturnSuccess)
+    return;

If this happens you'll leak "input" and "output".

+  // right side of the MBP to mean a negative x.

I assume "MBP" is MacBook Pro. Lets just say machine since this applies to all models.

Comment 55

[Doug Turner (:dougt)]

Attachment: patch v.v (cocoa widget implementation)

Comment 56

[Doug Turner (:dougt)]

Patch v.4 w/ minor nit fixed:

http://hg.mozilla.org/mozilla-central/rev/1fffd956a7f6

I am going to mark this fixed, and move the widget implementation to new bugs (specifically, going to obsolete the above cocoa patch and move it to a new bug).

Comment 57

[Doug Turner (:dougt)]

for those that care, bug 511902 has the cocoa love in it.

Comment 58

[Tom Dyas]

(In reply to comment #56)
> Patch v.4 w/ minor nit fixed:
> 
> http://hg.mozilla.org/mozilla-central/rev/1fffd956a7f6
> 
> I am going to mark this fixed, and move the widget implementation to new bugs
> (specifically, going to obsolete the above cocoa patch and move it to a new
> bug).

Noticed on the hg.mozilla.org/mozilla-central/ page for the changeset (and verified through a checkout) that both NS_ORIENTATION_EVENT and NS_CONTENT_COMMAND_EVENT_START are equal to 3800.  One of these constants should probably be changed ...

Comment 59

[Doug Turner (:dougt)]

ah... nice find!

Comment 60

[Doug Turner (:dougt)]

Attachment: fixes regression caused by duplicate IDs

Comment 61

[Eric Shepherd [:sheppy]]

Did this land on 1.9.2, or is this 1.9.3-only?

Comment 62

[Doug Turner (:dougt)]

i will land on 1.9.2 tonight.

Comment 63

[Olli Pettay [:smaug][[e-mail]]]

Please land this only once other related patches have 1.9.2 approval.

Comment 64

[Doug Turner (:dougt)]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/5eb3aae99146
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/354ed8b3c2e3

Comment 65

[Eric Shepherd [:sheppy]]

If X=0 indicates the device is parallel to Earth along the X axis, what do Y=0 and Z=0 indicate? I'm not sure where the balance points are for these two axes.

Comment 66

[Eric Shepherd [:sheppy]]

Also, are these values deltas (so that if the device is not moving, they're all zero), or do they represent the current orientation, regardless of current movement?

Comment 67

[Justin Dolske [:Dolske]]

This might help illustrate how the X/Y/Z axis changes depending on orientation:

https://people.mozilla.com/~dolske/tmp/seismo.html

X changes when you tilt left/right, Y changes as you tilt forward/back, and Z changes as the X-Y plane changes -- try holding your laptop level but upside down. The values are all relative towards the earth (gravity = 1G acceleration)

If you had a laptop in orbit (I'll volunteer!), these would all be 0(G) at any orientation, and would only change when accelerated along the respective axis. Here on earth you could also change change values without changing the orientation if you threw (accelerated) your laptop. For example, drop your laptop (nice and level) and Z will change from -1 to 0 while it's in free fall. Go ahead, try it now. :-)

The values are not deltas.

Comment 68

[Doug Turner (:dougt)]

please note that this is subject to change.  There has been some discussion to simply report the acceleration in g (that means, sitting at rest, your laptop will have a -1g on the Z access).

another helpful page is:
http://people.mozilla.org/~dougt/ori.html

Comment 69

[Eric Shepherd [:sheppy]]

Does this still work on MacBooks? I know it did at one point, but I see comments about removing Cocoa support, which makes me wonder.

Comment 70

[Doug Turner (:dougt)]

it should.  where did you read comments about removing cocoa support?

Comment 71

[Eric Shepherd [:sheppy]]

Never mind, was reading some obsolete info from broken patches. I'll play with the demos on the laptop so I get a better idea of what I'm writing about. Thanks.

Comment 72

[Eric Shepherd [:sheppy]]

Looks like Z is 1 if the device isn't moving vertically (indicating that the effect of gravity is the only acceleration in that axis), but gets lower if you move the device upward, in opposition to gravity. Y approaches -1 as you tilt the device toward you (toward its face) and 1 as you tilt the other direction. X approaches -1 as you tilt toward the right and 1 as you tilt toward the left.

(this comment is mostly a note for myself, but if this assessment is incorrect or needs refinement, please feel free)

Comment 73

[Eric Shepherd [:sheppy]]

Would appreciate if someone would review this:

https://developer.mozilla.org/en/nsIAcceleration#Accelerometer_values_explained

That information is a compilation of information based on comments here as well as my own observations, but there were some conflicts between the two, so it would be good to get someone who knows this stuff well (Hi dougt) to take a look.

The rest of the documentation is still in progress.

Comment 74

[Doug Turner (:dougt)]

it is documented correctly.  please mentioned that these value def. may change in the future.

Comment 75

[Eric Shepherd [:sheppy]]

OK, I've now got this documentation drafted and would appreciate feedback
and/or edits. I do need to add information about which platforms currently support this. Mac OS X, Win Mobile, and Maemo, or...?

https://developer.mozilla.org/en/DOM/window.onmozorientation
https://developer.mozilla.org/en/nsIDOMOrientationEvent
https://developer.mozilla.org/en/nsIAcceleration
https://developer.mozilla.org/en/nsIAccelerationListener
https://developer.mozilla.org/en/nsIAccelerometer

Comment 76

[Boris Zbarsky [:bzbarsky]]

> https://developer.mozilla.org/en/DOM/window.onmozorientation

For what its worth, that doesn't exist in the checked-in patch here...