601186 - Fennec UI is unresponsive while loading home page on startup

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect, P2)

Description

[Matt Brubeck (:mbrubeck)]

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.

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

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.

Comment 2

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Backtrace taken while spinner stops spinning

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

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Another

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

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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.

Comment 5

[(dormant account)]

(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?

Comment 6

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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

Comment 7

[Benedict Hsieh [:benedict]]

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).

Comment 8

[Mark Finkle (:mfinkle) (use needinfo?)]

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.

Comment 10

[Alon Zakai (:azakai)]

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.

Comment 11

[Benjamin Smedberg]

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.

Comment 12

[Mike Shaver (:shaver emeritus)]

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.

Comment 13

[Brad Lassey [:blassey] (use needinfo?)]

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.

Comment 14

[Mark Finkle (:mfinkle) (use needinfo?)]

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

Comment 15

[Aakash Desai [:aakashd]]

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