STR: 1. Open a bogus github URL, such as https://github.com/mozilla/404 AR: The Tatooine scene won't stop shaking, even when you are not moving the mouse. ER: The Tatooine scene is supposed to follow the mouse This is a regression in Firefox 14.
Chris, are you willing to find a regression range?
I believe the regression was in Nightly 2012-03-12. Here is the pushlog between Nightly 03-11 and 03-12: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6737b6762eb8&tochange=0ff816e5e992
Sorry, I think that regression range is correct, but too wider because I was testing a later build than I thought. I will find a narrower range.
The regression was in Nightly 2012-03-15, which the day Android's OMTC merged from maple to mozilla-central: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c71845b3b2a6&tochange=d0d13f09be44
Thanks for the regression range! This page is using device motion stuff, afaict. And on that date there were several changes to device motion events: bug 734391 and bug 734324 and possibly others. Doug?
tracking-firefox14: --- → ?
tracking-firefox15: --- → ?
tracking-firefox16: --- → ?
probably related. chris, do you know if github has the source available for this site. i can't deminimize the js in my head right now.
Assignee: nobody → cpeterson
tracking-firefox14: ? → +
tracking-firefox15: ? → +
tracking-firefox16: ? → +
Reassigning to Doug. This bug is likely a regression from his device motion changes.
Assignee: cpeterson → doug.turner
It is really hard to tell what is going on with their code and what is their intent. Reviewing the code, it looks like on systems where there are device events, they want to use them so that you can shake your device/laptop and see Tatooine move. On devices that do not support that, you can move the mouse around and see a simple thing. So, it looks like it is working if I understand what their intent was. In firefox 12, there were a number of bugs that we since fixed which could have caused sensor events from stop firing. I think what is happening in this case is that if you had two event listeners for a device sensor and removed one, you wouldn't get any further sensor events. :( That could the reason you don't see ff12 show the same behavior of ff13. I do not think there is bug here.
Given Doug's explanation I'm removing tracking.
status-firefox14: affected → wontfix
status-firefox15: affected → wontfix
status-firefox16: affected → wontfix
tracking-firefox14: + → -
tracking-firefox15: + → -
tracking-firefox16: + → -
(In reply to Doug Turner (:dougt) from comment #10) > I do not think there is bug here. Doug, Would it make sense to evangelize to github the behavior we're seeing, in order to see if it's what they were intending? Perhaps this can be fixed on their side?
yeah it would: https://twitter.com/dougturner/status/221066258588762113
Looks like they're using Plax, which is doing detection for motion support and assuming that means mobile. I "fixed" it with https://github.com/cameronmcefee/plax/pull/26 though that's not bulletproof. I'll reach out to somebody I know there to let them know what's up.
Hi Guys, Let me start out by saying I don't consider myself a developer. I write code that generally works, but isn't necessarily pretty or proper. If there's a better way to do something feel free to suggest it. The intended behavior is something similar to the mouse experience, where the pitch of your device will affect the "viewing angle" of the scene. A few FF versions back, I ran into a problem where a macbook sitting on a desk would still fire motion events. To try to mitigate that, I added a limiter that would see if if the device was moving beyond a certain threshold for a sustained amount of time. This helped smooth out reactions to bumping the computer, key strokes, or low motion events like the computer's fan. Code here: https://github.com/cameronmcefee/plax/blob/master/js/plax.js#L178 Plax essentially measures the distance from min to max where the input method falls and then moves a dom element a physical distance that percentage across a range specified by the user. It first tests for motion events. If motion events exist, it uses the device's angle to determine how far across the range it should move objects. If motion events don't exist, then the mouse position is use. Did that happen to answer the question? Let me know if I missed the mark. Cameron
yup, that makes sense. some sensors are just noisy. You can see this by loading http://dl.dropbox.com/u/8727858/physical-events/index.html Even on a perfectly still platform, you will see values change. We considering filtering inside of firefox so that these events would have less noise. However, we weren't sure if all app developers wanted this -- we'd have to choice some value for a low pass filter. This value might not be right for all applications. Instead, we decided to just return the raw sensor values. Now, it is fair to note that on the MBP, this accelerator is kind of crap. It isn't really meant for fine motion sensing. Instead, its sole purpose is to protect the hard drive during sudden motion (http://en.wikipedia.org/wiki/Sudden_Motion_Sensor). Other laptops have similar systems which we tapped into. So, for course purposes, it will work just fine. However, you'll see noise. I send you a pull request to add a low pass filter to plax. You may want to consider using that. You may also want to remove the min to max filtering you have. Let me know how I can help! For now, marking WONTFIX. Lets move this conversation to the pull requests.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
Sounds good. When I get a free moment I'll have a look at the pull request. Thanks!
You need to log in before you can comment on or make changes to this bug.