Closed Bug 500280 Opened 11 years ago Closed 11 years ago

clicking the preferences button takes a few seconds to switch screens

Categories

(Firefox for Android Graveyard :: General, defect)

ARM
All
defect
Not set
normal

Tracking

(fennec1.0+)

VERIFIED FIXED
Tracking Status
fennec 1.0+ ---

People

(Reporter: jmaher, Assigned: mfinkle)

References

Details

Attachments

(2 files, 1 obsolete file)

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.
is there anything in the javascript console?
I just checked this on my maemo device and verified the multi second delay but see nothing in the javascript error console :(
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.
tracking-fennec: --- → ?
Component: Windows Mobile → General
OS: Windows Mobile 6 Professional → All
QA Contact: mobile-windows → general
tracking-fennec: ? → 1.0+
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
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.
Attachment #411576 - Flags: review?(gavin.sharp)
Attachment #411576 - Flags: review?(gavin.sharp) → review+
Comment on attachment 411576 [details] [diff] [review]
Add a few more image preloads

In the name of perceived performance, I r+ thee
Assignee: nobody → mark.finkle
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...
Attached patch patch 2 (alternate method) (obsolete) — Splinter Review
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.
Attachment #412107 - Flags: review?(gavin.sharp)
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.)
Attachment #412107 - Flags: review?(gavin.sharp) → review+
(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.
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!).
(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
It still may help for the browser to appear before the XBL work is done.  Just a thought.
Duplicate of this bug: 534898
Attached patch patch 3Splinter Review
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 :(
Attachment #412107 - Attachment is obsolete: true
Attachment #417995 - Flags: review?(gavin.sharp)
Attachment #417995 - Flags: review?(gavin.sharp) → review+
pushed:
https://hg.mozilla.org/mobile-browser/rev/27df02e7bdfc

filed bug 535366 for doing a delayed init and removing the setTimeout
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.