Bug 485943 (DeviceOrientation)

Device Orientation Support

RESOLVED FIXED in mozilla1.9.3a1

Status

()

defect
RESOLVED FIXED
10 years ago
4 months ago

People

(Reporter: dougt, Assigned: dougt)

Tracking

(Depends on 1 bug, Blocks 2 bugs, {dev-doc-complete})

Trunk
mozilla1.9.3a1
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(status1.9.2 beta1-fixed)

Details

()

Attachments

(3 attachments, 8 obsolete attachments)

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).
Posted patch patch v.1 (obsolete) — Splinter Review
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).
Attachment #370019 - Flags: superreview?(jst)
Attachment #370019 - Flags: review?(jst)
The patch missed the interfaces.
Posted patch patch v.1 w/ interfaces (obsolete) — Splinter Review
Attachment #370019 - Attachment is obsolete: true
Attachment #370019 - Flags: superreview?(jst)
Attachment #370019 - Flags: review?(jst)
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.
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;
};
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.
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.
I wonder how to expose the initial orientation with events only approach.
Perhaps comment #4 is better after all.
I agree this should be a DOM event, not a callback.
I like the direction of comment #5
@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.
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.
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?
This kind of stuff should be done the DCCI way instead of using custom interfaces : http://www.w3.org/TR/DPF/
(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
(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.
@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.
(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();

}
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?
Posted patch patch v2 with Omnia Support (obsolete) — Splinter Review
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.
Posted patch patch v.1 (events) (obsolete) — Splinter Review
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?)
Attachment #370021 - Attachment is obsolete: true
Attachment #381084 - Attachment is obsolete: true
Posted patch patch v.2 (events) (obsolete) — Splinter Review
This also has a cocoa impl. that works on most macbooks.
Attachment #388260 - Attachment is obsolete: true
Attachment #390967 - Flags: review?
Attachment #390967 - Flags: review? → review?(Olli.Pettay)
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 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.
Attachment #390967 - Flags: review?(Olli.Pettay) → review-
Posted patch patch v.3 (events) (obsolete) — Splinter Review
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.
Attachment #390967 - Attachment is obsolete: true
Attachment #393328 - Flags: review?(Olli.Pettay)
Do you have any testcases for this? (even just manual tests)
Attachment #393328 - Flags: review?(Olli.Pettay) → review-
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 <dougt@dougt.org>
>+ * 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 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.
Does the patch fire MozOrientation every 200ms, even if nothing has changed?
Might make sense to fire the event only if something changes, or if there are
new acceleration listeners which haven't been notified.
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?
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?
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.
(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.
just to be clear -- that should not expose anything to web content. ;-)
Right. The only thing we expose to web content is possibility to add event listener for MozOrientation.
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.
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.
There is also the option to make interfaces non-scriptable.
I'm not sure when chrome would use the service and when events.
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?
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?
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.
from c++, and without a document handy, it is alot easier to use the interface.
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 :)
(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.
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?
Attachment #393328 - Attachment is obsolete: true
Attachment #393769 - Flags: review?(Olli.Pettay)
(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.)
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.
Could you please attach the testcase to this bug. Safer place and all...
Posted file test case
Attachment #394044 - Flags: review?
Attachment #394044 - Flags: review? → review?(josh.ain)
Attachment #394044 - Flags: review?(josh.ain) → review?(joshmoz)
Comment on attachment 393769 [details] [diff] [review]
patch v.4 (events w/o cocoa impl.)

With the aTypeAtom thing (if that works).
Attachment #393769 - Flags: review?(Olli.Pettay) → review+
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.
Attachment #394044 - Flags: review?(joshmoz) → review-
Attachment #394044 - Attachment is obsolete: true
Attachment #395838 - Flags: review?(joshmoz)
Attachment #393783 - Attachment is patch: false
Attachment #393783 - Attachment mime type: text/plain → text/html
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).
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Attachment #395838 - Attachment is obsolete: true
Attachment #395838 - Flags: review?(joshmoz)
Blocks: 511902
for those that care, bug 511902 has the cocoa love in it.
No longer blocks: 511902
Attachment #393769 - Flags: approval1.9.2?
(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 ...
ah... nice find!
Attachment #395862 - Flags: review?(Olli.Pettay)
Attachment #395862 - Flags: review?(Olli.Pettay) → review+
Blocks: 512345
Flags: in-testsuite?
Target Milestone: --- → mozilla1.9.3a1
Whiteboard: [doc-waiting-1.9.3]
Depends on: 517658
Attachment #393769 - Flags: approval1.9.2? → approval1.9.2+
Whiteboard: [doc-waiting-1.9.3]
Did this land on 1.9.2, or is this 1.9.3-only?
i will land on 1.9.2 tonight.
Please land this only once other related patches have 1.9.2 approval.
Depends on: 519173
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.
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?
Whiteboard: [doc-waiting-info]
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.
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
Whiteboard: [doc-waiting-info]
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.
it should.  where did you read comments about removing cocoa support?
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.
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)
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.
it is documented correctly.  please mentioned that these value def. may change in the future.
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
Blocks: 521902
Alias: DeviceOrientation
Blocks: 615597
> https://developer.mozilla.org/en/DOM/window.onmozorientation

For what its worth, that doesn't exist in the checked-in patch here...
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.