With the patch from bug 824677 landing the "show time to load" does not show any valuable data anymore. It's static ~340ms per load and does not represent any data about the real window load.

instead of firing appopen event when the app's iframe is displayed (and the app is just starting to load), fire appopen when the app is really loaded (it's document.load is fired). This gives us much more realistic time to load. The only other option would be to separate two events: - one for when the app iframe is open - one for when app is loaded

Comment on attachment 701401 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7576 Don't know why you are relying on appopen to do time counting. appopen is working as transition end event from long time ago, not by the way you described.

bah, not that easy. That works in DEBUG mode only. I guess that there's something about iframe CSP that prevents window_manager.js from setting eventListener on iframe. Chris, Vivien: should it be like that?

(In reply to Alive Kuo [:alive] from comment #2) > Don't know why you are relying on appopen to do time counting. > appopen is working as transition end event from long time ago, not by the > way you described. Oh, it's not me. It's ttlview: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/ttlview.js#L37 Does it mean we should have separate event for when the app launch ends?

Ok, I think I found a cleaner solution. I switched ttlview to use mozbrowserloadend which is a Browser API (https://wiki.mozilla.org/WebAPI/BrowserAPI) event for cold boot. On warm boot I still rely on appopen which means that the timer in fact shows two separate numbers depending on wherever the app is actually launching or just opening. This may be confusing to the user, since the open transition may take longer than app launch and then warm boot will take longer than cold boot (not in unagi case) so I added [c] and [w] to the display. This brings overall much more realistic numbers for app booting than we had before!

(In reply to Zbigniew Braniecki [:gandalf] from comment #3) > bah, not that easy. That works in DEBUG mode only. I guess that there's > something about iframe CSP that prevents window_manager.js from setting > eventListener on iframe. CSP is unrelated. document within <iframe mozbrowser remote> lives on another process; we can never access it's object and events synchronously, ever. (In reply to Zbigniew Braniecki [:gandalf] from comment #5) > I switched ttlview to use mozbrowserloadend which is a Browser API > (https://wiki.mozilla.org/WebAPI/BrowserAPI) event for cold boot. mozbrowserloadend might not be the event you are looking for either. It literally means when the browser spinner should stop -- which, doesn't exactly correspond to window.onload nor network activities (maybe loosely). > On warm boot I still rely on appopen which means that the timer in fact > shows two separate numbers depending on wherever the app is actually > launching or just opening. This may be confusing to the user, since the open > transition may take longer than app launch and then warm boot will take > longer than cold boot (not in unagi case) so I added [c] and [w] to the > display. |appopen| custom event, internal to system app, always fires when transition ends; we do wait for painting before starting the transition, but there is a 300ms upper cap. If, by warm boot, you are measuring the paint time, you should patch window_manager.js and use |addNextPaintListener| API.

Thanks for the feedback! (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #6) > CSP is unrelated. document within <iframe mozbrowser remote> lives on > another process; we can never access it's object and events synchronously, > ever. Ah, ok. > (In reply to Zbigniew Braniecki [:gandalf] from comment #5) > mozbrowserloadend might not be the event you are looking for either. It > literally means when the browser spinner should stop -- which, doesn't > exactly correspond to window.onload nor network activities (maybe loosely). No, that's exactly what I'm looking for - equivalent of spinner stop within the context of a gaia app. I want to know when the app is "ready". In order to measure performance improvements or regressions of the app's startup. Being able to measure how much time it took between app start and when "spinner stopped" sounds like the closest thing we will have. > |appopen| custom event, internal to system app, always fires when transition > ends; we do wait for painting before starting the transition, but there is a > 300ms upper cap. If, by warm boot, you are measuring the paint time, you > should patch window_manager.js and use |addNextPaintListener| API. Here I want to measure how much time it took between the initialization of app opening and the moment when the app was open, focused and ready to be used. It sounds like reacting to when transition ends is the right call here?

after updating gecko, I don't see the regression anymore, so I'm closing this bug and moving my pull request to the proper bug - bug 825137

let's keep it open, I'd like to get into that remaining 100ms between tap and appwillopen ;)

wrong bug id... sorry for spam!