Steps to reproduce: 1. Make sure the "Start page" setting is the default "Fennec Start" (about:home) 2. Launch Fennec 3. While the throbber is still spinning in the urlbar, try to drag the page. Expected results: Page pans. Actual results: Nothing happens. We should make sure that input handlers are initialized as early as possible on startup, and figure out if anything is blocking the main thread or otherwise preventing us from responding to input.

Not limited to about:home. I changed my startpage to about:firefox (with basically zero JS in the page) and we still froze until the favicon load.

Very unscientific, just broke in gdb when the spinner stopped spinning. This looks like startup cache blocking on a write flush during close().

Looks like Sync this time, "weave/toFetch/clients.json".

I caught a third one with close() at the top of the stack, but it originated from pure JS and I didn't have the patch from bug 600304 to get a JS stack.

(In reply to comment #4) > I caught a third one with close() at the top of the stack, but it originated > from pure JS and I didn't have the patch from bug 600304 to get a JS stack. Can we not just use functiontimer logs instead of blind debugging?

Of course we can. I was shotgun profiling to see if anything glaringly obvious showed up.

The patch in bug 593349 should help with this by batching more writes together and pushing them off until later. We do want to move the write off the main thread eventually, though (bug 586859).

Bug 600815 landed a patch that should remove all Weave access during home page loading. Unfortunately, we still see unresponsive panning during the load. This points to something else causing the problem.

1. Is it surprising that the UI would lock up during loading of a local page? It should block just like desktop Firefox does. 2. The unresponsiveness is brief, around 1-2 seconds on a Galaxy S, and things happen on the screen meanwhile, so I'm not sure users would be surprised that it won't be fully responsive at that point.

I see this on nightly builds and it's a huge deal... I keep thinking that Firefox is hung, when it's just taking a ridiculously long time to render the page. It takes 5-10 seconds, sometimes more for me on an N1. The time is probably related to the size of my synced bookmarks/history, which is pretty large.

Ah ha! I thought that this had been fixed, but I bet it was when I blew away my history in the wrong profile and didn't notice until the sync had completed the next day.

I looked at this a while back, and my profiling pointed the finger at places. Let's see if the work to get places and sync off the main thread lands.

Bug 617859 removed NSS startup/initialization from the home page. It has a dramatic affect. So much so that I am marking this FIXED. Reopen if you still find the page unresponsive

verified FIXED on build: Mozilla/5.0 (Android; Linux armv71; rv:2.0b9pre) Gecko/20101227 Namoroka/4.0b9pre Fennec/4.0b4pre