OK, looked this over with: http://people.opera.com/richt/release/demos/orientation/artificialhorizon/ on both B2G browser and Native Fennec (Nightly 14.0a1) 2012-03-29. For all tests phones were held, top to bottom at 90 degrees perpendicular to table. Results are as below: B2G: rotate on z axis - widget responds correctly (horizon adjusts appropriately) rotate on y axis - widget responds correctly rotate on x axis - widget responds correctly Nightly: rotate on z axis - widget responds correctly *rotate on y axis - horizon adjusts 90 degrees opposite to reality *rotate on x axis - horizon adjusts 90 degrees opposite to reality So arguably the bug here is in Nightly, but not B2g! I will file one accordingly.
as i mentioned in the github bug, there isn't enough information. What device type are you using? What were the values of accelerationIncludingGravity when the device was resting on a study desk? How did they change when you rotated the device? This URL might help: http://dl.dropbox.com/u/8727858/physical-events/index.html Please reopen when you have the asked for information.
Ran http://dl.dropbox.com/u/8727858/physical-events/index.html on two identical Samsung Nexus S phones (same hardware models) facing in similar direction with one running b2g (m2.5-candidate-5.1) and one running android (2.3.3) & (Nightly 14.01a 3.30.2012) Here are the results for one scenario: 1. Laying phone flat on table, earspeaker facing away. Android & Fennec nightly ~app freezes so need to refresh after laying down phone~ Acceleration: acceleration.x: -0.03457066.. accceleration.y: -0.03325264.. acceleration.z: -0.0671310424.. Acceleration Including Gravity ~static, only updated on reload page~: accelerationIncludingGravity.x = -0.3830... accelerationIncludingGravity.y = -0.26815... accelerationIncludingGravity.z = 9.921571... Time Between Motion Events: 100 Milliseconds Rotation Rate: rotationRate.alpha = -1.39999... rotationRate.beta =-0.007000... rotationRate.gamma = -0.6299999... Orientation: orientation.alpha= 89.890625 orientation.beta= -1.484375 orientation.gamma= -2.20315 B2G: ~app is constantly updating so no need to refresh.~ Sections are noted where values are continually updating. Acceleration: acceleration.x: accceleration.y: acceleration.z: Acceleration Including Gravity ~constantly updating~ accelerationIncludingGravity.x = -0.01..to 0.15.. (range over 10 seconds) accelerationIncludingGravity.y = 0.51.. to 0.63.. accelerationIncludingGravity.z = 10.1.. to 10.24 Time Between Motion Events: 100 Milliseconds Rotation Rate: rotationRate.alpha = rotationRate.beta = rotationRate.gamma = Orientation: orientation.alpha= 208.375 orientation.beta= 4.84375 orientation.gamma= 0.390625 A few things can be inferred here. On Android& Native, acceleration.x, y, z show (static) values for each; on B2G, nothing is shown. On Android & Native, Acceleration Including Gravity only updates once, on load, then does nothing. On B2G Acceleration Including Gravity updates constantly, even if the device is laying flat. On Android & Native, Rotation Rate updates values once, on load; on B2G values remain blank. On Android & Native Orientation updates values once, on load; on B2G values are updated every 100 ms. Of interest here: on B2G, orientation alpha (updating constantly) ranges between 150 - 160; on Native Fennec OA is 215.9... (static) on B2G, orientation beta 3.0 to 3.4, on Native Fennec -1.26525 (static) on B2G, orientation beta -0.03 to 0.03, on Native Fennec -1.26525 (static)
Here is a video of the test in action (only lying on table), showing the inconsistent behavior when phone is just resting on desk: http://videos-cdn.mozilla.net/serv/drafts/phone%20test.webm Hope this is the information you need.
It was difficult to test Acceleration Including Gravity on the Android & Native device because it doesn't update automatically. Accordingly on the B2G device values update and change as the device is rotated. Is there a need for rotating either device from one specific orientation to another to test specifics?
john, we fixed a bug yesterday that caused sensor data to not be updated. So, now this bug isn't incomplete. It is a dup of 740252 Please retest. Based on the results that you showed (even w/ the static data), i do not see a problem
So the sensor updating issue on native fennec appears fixed. Still, the orientation issue still remains broken IMO. Behold the following video of "artificial horizon". The Native Fennec (on the right, busted) is running the nightly from yesterday (4/1/2012) and the B2G version (left) is running m2.5-candidate-5.1 (tried newer B2G install from today's pull, but much bustage, so reverted to RC): http://www.youtube.com/watch?v=wF6KVPVrMSo&feature=youtu.be You will see that the Native Version lags, and the horizon on native version is exactly opposite as on B2G, which adjusts the horizon correctly. Also, from http://dl.dropbox.com/u/8727858/physical-events/index.html: note the orientation alpha, beta, gamma discrepencies between the 2 devices (now with the values constantly updating on both, with both devices laying in identical positions the table): B2G Native alpha: 174-188 247.3 - 247.5 beta: 2.7-3.5 -11 - -0.3 gamma: 0.39-0.53 -1.4 - -2.3
John, is this still a problem?
This bug is in the beta release notes: http://www.mozilla.org/en-US/mobile/19.0beta/releasenotes/
marco, Why would you release node an incomplete bug? Is this really a bug -- can you reproduce it?
I mean it should be removed from the release notes if it's invalid.
I'm not testing fennec and it's out of my scope. I only happened to see it when I needed to check fennec for comparison to something on B2G. Please ask someone in QA who's scope is fennec to recheck this.
Works for me on a current Fennec nightly and a LG Nexus 4 and Samsung Nexus S.