Description: Browser is at a minimum unstable, most cases crashes, after launching browser and entering a website. Crashes during loading of webpage. Repro Steps: 1) Updated Unagi v1.2.0 to Build ID: 20130718030209 2) Open browser 3) Type website (i.e. cnn.com) Actual: Device crashes Expected: Webpage is loaded and viewable. Environmental Variables Build ID: 20130718030209 Gecko: http://hg.mozilla.org/mozilla-central/rev/f26e4c26ce4a Gaia: 4ec7c428f6a63a44f888ea6f6ade0385c89ae305 Platform Version: 25.0a1 Build Link: https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-central-unagi/2013/07/2013-07-18-03-02-09/ Notes: Repro frequency: 2/2, 100% Q Analysts Team Priority: Pri 1 Crash Report: https://crash-stats.mozilla.com/report/index/dfde895a-49a7-40a6-b7d9-7123f2130718 reference: https://bugzilla.mozilla.org/show_bug.cgi?id=892963#c36

Milan - We're seeing this quite often in our daily smoke test runs on central. Can you help find an assignee to look into this bug?

I don't necessarily see crashes on hamachi, but it isn't pretty. I'll assign this by Tuesday, I want to make sure I have a chance to talk to the team, and the long weekend is getting in the way.

I guess I'll take this bug. I'll look into it on Monday.

I definitely cannot reproduce on Hamachi. If this crash is specific to Unagi, do we care about it? (I've been told a few times to stop using Unagi's myself). The stack trace in the crash report in comment 0 points to TaskThrottler, which according to hg history is mostly written by Anthony Jones and reviewed by Benoit Girard and originally by Chris Jones. CC'ing.

Spoke with Allen - he's working on getting clearer STR here. Right now, development is mostly using unagis since the reference devices aren't available yet (Hamachi isn't widespread in our development group). So this does remain important until we resolve the reference device problem.

Here are my repro steps: 1. Launch the browser and navigate to a site, espacially one with lots of content (eg yahoo.com). 2. Scroll down the page. The page will eventually freeze and become unresponsive, forcing the user to close the browser completely and reload it. The length of time varies, but it's never more than a minute.

(In reply to ckreinbring from comment #6) > Created attachment 785950 [details] > Log of browser load and freeze > > Here are my repro steps: > > 1. Launch the browser and navigate to a site, espacially one with lots of > content (eg yahoo.com). > 2. Scroll down the page. > > The page will eventually freeze and become unresponsive, forcing the user to > close the browser completely and reload it. The length of time varies, but > it's never more than a minute. The issue cited here is a different bug - bug 901339. This bug involves a crash. If you manage to reproduce this bug, you should get a crash report URL that matches the crash signature in this bug.

Checking the reports over the past 28 days, I'm not seeing this crash present since July 19th. https://crash-stats.mozilla.com/report/list?product=B2G&query_search=signature&query_type=contains&reason_type=contains&date=2013-08-06&range_value=28&range_unit=days&hang_type=any&process_type=any&signature=mozilla%3A%3Alayers%3A%3ATaskThrottler%3A%3ATaskComplete%28mozilla%3A%3ATimeStamp+const%26%29

Okay, so I reproduced this crash by going to cnn.com in the browser and immediately, you get an OS restart crash on a 7/19 build.

Using the same STR on comment 9, I can't reproduce this crash on a 8/5 central build. I'm seeing different APZC bugs now, but not the crash as filed. Resolving as works for me.