User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20130420 Firefox/23.0 Build ID: 20130420031010 Steps to reproduce: 1) In FF Nightly on OSX 10.8.x, go to this URL: http://www.flohofwoe.net/demos/dragons_asmjs.html or http://www.flohofwoe.net/demos/dragons.html 2) Rotate camera with Left-Mouse-Button + Movement, notice how the demo responds smoothly. 3) Add more dragons with "cursor up" (about 9x), and try to rotate the camera, notice how the camera doesn't properly react, actually all input on the browser tab seems to be affected. Other browsers, and the public version of FF doesn't have this problem, this is also a relatively new bug in Nighly, a few weeks ago everything worked as expected, but I can't say exactly when the problem started to show up. I couldn't reproduce the problem on Windows, also another Mac with OSX 10.7.x also has the problem but not as badly. Also, after fiddling around with other input elements (scrolling the text box etc...) the problem suddenly disappeared, even after reloading the page. But open the demo on a new tab, and the input lag happens again after adding dragons.

The profile shows buffer swapping as the most expensive thing going on here.

Andre Weissflog, could you use mozregression to find a regression range, please. See http://harthur.github.io/mozregression/ for details.

Last good build was 2013-04-12, first bad build was 2013-04-13, I'm currently trying to bisect deeper, but building takes a lot of time.

Bisecting deeper it says: The first bad revision is: changeset: 128501:29a5fd2889f3 user: Guilherme de Araujo <guimdearaujo@gmail.com>, Brandon Waterloo <brandon.waterloo@gmail.com> date: Wed Apr 10 14:38:26 2013 -0400 summary: Bug 851128 - Introduce custom recognition for the double-tap gesture. r=smichaud Regression found using mozcommitbuilder 0.4.10 on darwin at 2013-04-21 19:48:33 Not 100% sure though because the debug build is very slow for this demo in any case, and as I wrote above, the bug "disappears" from time to time. Hope this helps.

On the other hand, looking through the bug comments, this *is* an OSX and input-related change, so it might be it.

See also bug 863841, which will essentially revert bug 851128 and implement differently using the Cocoa NSResponder method instead of a custom recognition.

I was able to reproduce the issue on OS X 10.8.2 when using a relatively up-to-date un-patched Nightly on this page: http://www.flohofwoe.net/demos/dragons.html (NOTE: on a trackpad only, not on a mouse--on mouse, everything works fine) Fortunately, the patch from bug 863841 seemed to fix the problem for me. Could somebody please verify that? Also, if you're using Lion (10.7.*), we aren't sure that the method in the patch works for Lion, so if you could test that as well, that'd be sweet! HOWEVER, this page causes a "Segmentation fault: 11" every time either with or without the patch, which is a whole new can of worms: http://www.flohofwoe.net/demos/dragons_asmjs.html Here's what GDB found for me: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 js::Vector<js::ion::MBasicBlock*, 1ul, js::ion::IonAllocPolicy>::append<js::ion::MBasicBlock*> () at /Users/firefox/Firefox/mozilla-central/obj-x86_64-apple-darwin12.2.0/dist/include/js/Vector.h:846 846 REENTRANCY_GUARD_ET_AL; Whatever the segfault is, it is well beyond my area of expertise. I'm going to try a more recent Nightly build in a few minutes, if the issue still exists, I'll file a bug.

The asm.js version doesn't run for me as well, but only with the Debug-Nightly-Builds. I'll notify the guys on the emscripten of this. Thanks for looking into this.

> 3) Add more dragons with "cursor up" (about 9x) What does this mean?

(In reply to Steven Michaud from comment #10) > > 3) Add more dragons with "cursor up" (about 9x) > > What does this mean? Press the Up arrow key 9 times until there's several hundred dragons. Then, camera panning with trackpad is super laggy/jerky.

Thanks, Brandon, for the info. I can reproduce this bug on both OS X 10.8.3 and 10.7.5. In my (very brief) testing it actually seems to be worse on 10.7.5 (though this may just be an accident). Brandon, I think you should back out your patch for bug 851128. Your patch for bug 863841 has problems of its own, and we probably won't be able to land it for a while. Or I can back out your patch for bug 851128 myself, since I have commit privileges.

Since I don't have commit privileges, you should back it out. Thanks!

Now that the bad patch for bug 851128 is backed out, I tried this again and the problem seems to be fixed. Can anyone confirm, and if so, can we mark this bug as fixed?

The backout of bug 851128 landed on mozilla-central too late to get into today's mozilla-central nightly. It'll be in tomorrow's, though.

Cannot reproduce the problem in Nightly 2013-04-24, looks good. Only thing I noticed... were those Nightly updates always only 5MB, I seem to remember they've been much bigger...?

Marking this fixed on the strength of comment #16.

(In reply to comment #16) > Only thing I noticed... were those Nightly updates always only 5MB, I seem to > remember they've been much bigger...? Typically if you update to the next Nightly, you'll get a "partial mar" which is basically a binary diff between the two builds, which is a lot smaller. If you download a nightly further into the future, you'll get a "complete mar" since we don't generate those diffs between all builds. "mar" is the archive format that we use to package our updates into.

I can't reproduce this issue with the Nightly from 2013-04-13, on a Mac OSX 10.8.3 machine in 32bit mode, using the STR from the description. Does anyone have any thoughts/suggestions?

Marking [qa-] since QA cannot reproduce the original issue as described, thus won't be able to reliably verify this is fixed. Andre, if you can no longer reproduce this in the latest Beta, please set this bug to VERIFIED FIXED. Thanks

Confirmed fixed in current Firefox 23 Beta. As I remember it was a trackpad-only thing and not related to emscripten or WebGL at all, but instead some multi-touch gesture code on OSX.

Thanks Andre.

Andre is correct; it was related to some work on recognizing multi-touch gestures. All of the gesture recognition that was causing problems has been replaced; through some trial and error and a lot of research we found the correct way to recognize multi-touch gestures (in particular, double tap) on OS X. This bug was originally caused by one of my changes, and subsequently fixed by one.