While profiling bug 914913 we noticed that a reflow was occuring later in the load just after alphaScroll.init(). This is occurring because the scrollbar hit targets are being filled out dynamically. In theory this could allow us to have different scrollbar targets based on locale or other settings, but right now its hardcoded to ascii A-Z and '#' for contacts without names. Since the content is essentially static, we can avoid the reflow here by simply specifying the hit targets upfront in the index.html. This video shows the contacts app launch with a statically defined scrollbar and the patches from bug 907907: https://www.dropbox.com/s/6x10ycv5chwv65q/20130923_static_scrollbar.mov Launch time is ~1.7 seconds with both these changes. Pull request to follow shortly.

Jose, please see the attached pull request. This simply moves the content for the scrollbar from a templated process to being statically defined in index.html. The content was hardcoded anyway and this avoids a reflow during load. Thanks!

Hi Ben, Please see my suggestions on GitHub. Don't hesitate to contact me for any help. thanks, best

Thanks Jose! As you suggested on Github, I investigated keeping the template code, but using a document fragment to minimize touch points with the live DOM. Unfortunately, it looks like the reflow still occurs. If you look around time 34420 you can see that a style flush, layout, and paint occurs right after the initAlphaScroll() call: http://people.mozilla.org/~bgirard/cleopatra/#report=40d24f7ac5c4c368661385ee9038e1a1fca048a1 I understand that it would be nice to have this configurable in the javascript, but currently we're not really taking advantage of that. The code in contacts_shortcut.js always populates the scrollbar with the same values: var alphabet = []; for (var i = 65; i <= 90; i++) { alphabet.push({ anchor: String.fromCharCode(i) }); } alphabet.push({ anchor: '#' }); utils.templates.append(jumper, alphabet); It seems that if we ever need to dynamically change this content we could add these 5 or so lines back in. Until then I'm not sure it makes sense to penalize the startup process for added configurability we're not using. Thoughts? Thanks again for the review.

Comment on attachment 808759 [details] Pull request at https://github.com/mozilla-b2g/gaia/pull/12373 As per comments on GH. Once the issue have been fixed, please ask for another review.

(In reply to Jose M. Cantera from comment #4) > Comment on attachment 808759 [details] > Pull request at https://github.com/mozilla-b2g/gaia/pull/12373 > > As per comments on GH. Once the issue have been fixed, please ask for > another review. Ah, sorry. I didn't see there were other comments further down.

Comment on attachment 808759 [details] Pull request at https://github.com/mozilla-b2g/gaia/pull/12373 Updated pull request that addresses review feedback. The code will now check to see if any templates are present in order to support the importer code. I also went ahead and used a doc fragment for that dynamic case. As an aside, I personally would prefer to just make these both statically defined in the html, but defer to Jose on this. I see that the templating makes things very flexible, but it just seems we're not currently using that flexibility since the javascript hardcodes the hit targets anyway. Its likely there are future plans here I'm not aware of. In any case, I've verified that both the static and dynamic paths work. I also verified again with profiling that the static path avoids a reflow. Thanks again for the review!

Comment on attachment 808759 [details] Pull request at https://github.com/mozilla-b2g/gaia/pull/12373 good work, Ben thanks!

Uplifted d8749293b230b2f2d972ec6444a5631cd4819bdb to: v1.2: a626ed3c58753573ad4511ba5420135681e2afe5