If I open three tabs to google, I get a slow script warning every time on the third. Backtrace shows that we're dealing with either MozScrolledArea or MozAfterPaint messages from the child.
This time I got it on the second tab. What's interesting is that the backtrace always shows a JIT in progress, as demonstrated in the attachment.
Note that the js_Interpret, js_fun_apply, js_Invoke cycle is evaluating Util.bind as far as I can tell.
This seems to occur because the browser viewport rectangle contains gigantic numbers after opening a new tab, and the tile manager just keeps chugging away trying to deal with them. The giant numbers come from the zoomLevel being 800 instead of 1, which in turn comes from the browser viewport being [0,0,1,1] and the zoom level being calculated as page width / viewport right.
Josh tracked this down to bug 557222: http://hg.mozilla.org/mobile-browser/rev/3f5066602cdb That call produces the gigantic numbers for viewport and zoomlevel
Created attachment 459202 [details] [diff] [review] patch This is probably a regression from bug 576396. This patch is a simple fix, as long as there are no side effects from changing the initial viewport size from 1 pixel to 800. (There aren't as far as I can tell. It does not regress bug 557222.) Do we need some more robust checking in getPageZoomLevel to prevent this from getting triggered some other way? We do have kViewportMinWidth=200, which prevents pages from setting their own width to 1 pixel.
Verified fixed on: Mozilla/5.0 (Android;Linux armv7l;rv:9.0a1)Gecko/20110920 Firefox/9.0a1 Fennec/9.0a1 Device: HTC Desire OS: Android 2.2