500280 - clicking the preferences button takes a few seconds to switch screens

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Joel Maher ( :jmaher ) (UTC -8) (PTO'ish until July 5)]

on the latest build of Fennec for windows mobile on my HTC Touch Pro device, I launch fennec and get about:firstrun.  I pan over to reveal the right strip.  I click on the preferences icon and nothing happens.  I click it a few more times and still nothing happens.  Finally it loads about 4 seconds later.

Comment 1

[Doug Turner (:dougt)]

is there anything in the javascript console?

Comment 2

[Joel Maher ( :jmaher ) (UTC -8) (PTO'ish until July 5)]

I just checked this on my maemo device and verified the multi second delay but see nothing in the javascript error console :(

Comment 3

[Joel Maher ( :jmaher ) (UTC -8) (PTO'ish until July 5)]

this is still a problem in beta3 on winmo and maemo.  This goes along the "browser is so slow" complaint that everybody outside of mozilla says about Fennec.

Comment 4

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

I am pretty sure this is related to loading the preference values into the UI. In profiles, I see the UI toggles being set 3 times.

This is also related to the border-image CSS technique used on the buttons and the toggles. That is bug

Comment 5

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

bug 516645

Comment 6

[Benjamin Stover (:stechz)]

Attachment: Add a few more image preloads

This helps even more with perceived perf.  Adding the preferences highlight button to the cache makes button responsiveness much better.  Adding the toolbar buttons prevents a reflow after preferences have been shown.

I know there's a balance to be struck here, but I think these images are particularly critical.

Comment 7

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

Comment on attachment 411576 [details] [diff] [review]
Add a few more image preloads

In the name of perceived performance, I r+ thee

Comment 8

[:Gavin Sharp [email: [e-mail]]]

I noticed while testing this that the caching only helps if you open the side pane shortly after startup.

I think the cache's default expiration time is pretty low (10 seconds?), so this may not be all that useful after all...

Comment 9

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

Attachment: patch 2 (alternate method)

We use hidden=true" on a few UI elements so we can reduce the startup time for elements which are not immediately visible. We make them visible later, when they are needed.

Doing this might save some cycles during startup, but it makes the first open of the panel take extra long because the XUL/XBL is being initialized for the first time.

This patch removes the hidden="true" trick for the panelUI. It moves the panelUI offscreen by default. After the first open, we continue to use the hidden method to show hide, but at that point the XUL/XBL is initialized.

With this patch, the preferences panel displays very quickly. The startup time does not seem affected much at all.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 412107 [details] [diff] [review]
patch 2 (alternate method)

This is fine technically, but I have a hard time making the call on whether it's the right tradeoff. It probably is...

(We need us some http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#86 , I think. I'll file it.)

Comment 11

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

(In reply to comment #10)
> (From update of attachment 412107 [details] [diff] [review])
> This is fine technically, but I have a hard time making the call on whether
> it's the right tradeoff. It probably is...

This patch does add about 1.6 secs to startup, while making the display of the preferences almost instant. Two other patches in bug 529074 and bug 528593 will help offset this by about 800ms. I want to get some additional speedups before landing this patch.

Comment 12

[Benjamin Stover (:stechz)]

What if we set hidden="false" after startup has completed, perhaps in our first onresize event?  This might help perceived startup time.  It may also cut down on whatever crazy reflows might be occuring on startup (it should not add 1.6 seconds!).

Comment 13

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

(In reply to comment #12)
> What if we set hidden="false" after startup has completed, perhaps in our first
> onresize event?  This might help perceived startup time.  It may also cut down
> on whatever crazy reflows might be occuring on startup (it should not add 1.6
> seconds!).

No, it doesn't. By the time we could set hidden=false again, the damage is done.

It's not the reflows that take the time. It's the fact that XBL constructors are not fired on hidden elements. My plan is to use hidden=true on the pages of the deck itself. This would mean we would use hidden=false on the outer panel and the preference page.

That should reduce the 1.6s to ~600ms - 800ms

Comment 14

[Benjamin Stover (:stechz)]

It still may help for the browser to appear before the XBL work is done.  Just a thought.

Comment 16

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

Attachment: patch 3

Updated patch

Happily, based on Talos Ts testing, this patch has zero affect on startup time, but still allows for fast preference display.

Sadly, it uses a setTimeout :(

Comment 17

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

pushed:
https://hg.mozilla.org/mobile-browser/rev/27df02e7bdfc

filed bug 535366 for doing a delayed init and removing the setTimeout

Comment 18

[Aakash Desai [:aakashd]]

I like on builds:

Mozilla/5.0 (X11; U; Linux armv7l; Nokia N900; en-US; rv:1.9.2b5pre) Gecko/20091218 Firefox/3.6b5pre Fennec/1.0b6pre

and

Mozilla/5.0 (X11; U; Linux armv6l; Nokia N8xx; en-US; rv:1.9.3a1pre) Gecko/20091218 Firefox/3.7a1pre Fennec/1.0b5