Description: The first page of FTU is the language selection page. The device now displays this page with an empty language list for 4 to 5 seconds before the list actually shows up. STR: 1) Flash to today's 3.0 Flame 2) Observe the device entering FTE after flashing Expected: The language list is loaded and displayed at the same time as the language selection page shows up Actual: The language selection page shows up with an empty language list for 4 to 5 seconds before the list shows up. Video demonstrating the issue: https://www.youtube.com/watch?v=nAJ5T68kd2w Repro rate: 5/5. This issue occurs regardless of memory settings. Device: Flame (KK, full flashed, 319/1024MB) BuildID: 20150609081840 Gaia: ea27c4ed5b6083c9e21d233d4804372ac4d5d353 Gecko: e10e2e8d8bf2 Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67 Version: 41.0a1 (3.0 Master) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

v2.2 seems unaffected. 1 out of 3 attempts I tried, the list took about 2 seconds to show up, the rest two attempts showed the list immediately. Device: Flame 2.2 (full flashed 319MB KK) BuildID: 20150609081832 Gaia: 06edb0f8db7c2f45cde54401a8593663059861a4 Gecko: 239c59921129 Gonk: bd9cb3af2a0354577a6903917bc826489050b40d Version: 37.0 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

I'm particularly interested in whether this occurs before bug 1094759 landed.

b2g-inbound regression window: Last Working Device: Flame BuildID: 20150604012244 Gaia: e0fbadeb78a96137f071d9be7a47ef9fe882d17f Gecko: 64ce149fabf1 Version: 41.0a1 (3.0 Master) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0 First Broken Device: Flame BuildID: 20150604020845 Gaia: c1ef854924f18357832ddcf98dc6c42391d5599e Gecko: 4f7e7631e277 Version: 41.0a1 (3.0 Master) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0 Last Working Gaia & First Broken Gecko - no repro Gaia: e0fbadeb78a96137f071d9be7a47ef9fe882d17f Gecko: 4f7e7631e277 Last Working Gecko & First Broken Gaia - repro Gaia: c1ef854924f18357832ddcf98dc6c42391d5599e Gecko: 64ce149fabf1 Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/e0fbadeb78a96137f071d9be7a47ef9fe882d17f...c1ef854924f18357832ddcf98dc6c42391d5599e Looks like comment 2 suspected the right bug. This was caused by changes made in bug 1094759.

Alive, can you take a look at this please? This might have been caused by the landing for bug 1094759.

Hmm...I don't think system has something to do here. I guess in the past we just wait for full loaded of the whole system app before hiding init logo. Now the startup is faster than before... My problem is what do we do here in FTU to show the lang list? I don't know when FTU is ready to show so I just use the mozbrowserloadend event. Sam are you familiar with this?

> My problem is what do we do here in FTU to show the lang list? I don't know > when FTU is ready to show so I just use the mozbrowserloadend event. Sam are > you familiar with this? I think from the system app's point of view, mozbrowserloadend is probably the right way to go. I'll need to dig a little to figure out where that 3-4 seconds is coming from. I do know the language picker is filled from /shared/resources/languages.json, which is loaded by the LanguageList (/shared/js/language_list.js) The data file is linked in the index.html - maybe a prefetch will help here? In all cases we know that the language picker will be required for the FTU UI, so maybe there's more shuffling of load order I can do there. I'm not really clear why bug 1094759 has exposed this issue, but it seems like the fix should be in the FTU app. I'll take the bug, but if you have any other pointers I would welcome them.

The language list does take some time to load is it has to load data and multiple settings, but that should be happening out of band as far as the system app as is concerned (and mozbrowserloadend) so why bug 1094759 regressed this is still unknown. Maybe it is simply a side-effect of loading the system app more efficiently that there's more contention for the main thread which delays FTU's loading? I'm blocking this on bug 1193369 so we get a baseline to work from. I have a WIP that reduces the time to populate the language list somewhat, but I'm starting to think there is no quick fix here. Early results from bug 1193369 show frankly pretty awful startup times (3-5 seconds); on the plus side there should be low hanging performance fruit to pick from that.

While b2g may live on, FTU will not